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

From: "Jozef Babiarz" <[email-masked]>
Date: Sun, 3 Feb 2008 22:37:49 -0500

Ruediger,
On section 3.3, yes, we are in agreement.

Regards, Joe
email:[email-masked]
Telephone:613-763-6098

-----Original Message-----
From: Geib, Ruediger [mailto:[email-masked]] 
Sent: January 29, 2008 3:18 AM
To: Babiarz, Jozef (CAR:0S03)
Cc: [email-masked]
Subject: AW: [PCN] Review of pcn-architecture-02 draft

Joe,

my response to two of your comments in line (further down).

Where I'm not commenting I accept or agree with your 
response.

Regards,

Ruediger 

| -----Ursprüngliche Nachricht-----
| Von: Jozef Babiarz [mailto:[email-masked]] 
| Gesendet: Montag, 28. Januar 2008 17:42
| An: Geib, Rüdiger; [email-masked]
| Betreff: RE: [PCN] Review of pcn-architecture-02 draft
| 
| Ruediger, see comments below.
| 
| Regards, Joe
| email:[email-masked]
| Telephone:613-763-6098
| 
| -----Original Message-----
| From: Geib, Ruediger [mailto:[email-masked]]
| Sent: January 17, 2008 5:34 AM
| To: Babiarz, Jozef (CAR:0S03); [email-masked]
| Subject: AW: [PCN] Review of pcn-architecture-02 draft
| 
| Hi Joe,
|  
| some comments on your comments:
| 
| One general remark is whether we should talk of "interfaces" 
| (instead of links) whenever PCN node-functionalities are 
| addressed. Up to now, there's a mix in the text.
| [Joe] Logically the PCN metering and marking is applied to a 
| link between two nodes. Physically, a vendor will implement 
| metering and marking on an interface to or from a node. My 
| view is that in an architecture document it should be worded 
| so that equipment vendors have a choice where they build the 
| metering and marking function. 
| 
| 
| You introduce the concept of PCN functionality on either 
| incoming or outgoing interfaces. PCN doesn't work, if there's 
| a sequence of nodes
| 
| Node1: outgoing IF - Node 2: incoming IF - Node 3: outgoing IF, 
| 
| there's a link between node 2 and 3 without PCN functionality 
| on any interface. So a domain shouldn't mix these nodes. I'd 
| prefer PCN functionality on outgoing IF's, if this is closer 
| to todays DiffServ implementations.
| [Joe] Yes. That is an issue. I'm suggesting that vendor of 
| the node specifies on what interface(s) PCN metering and 
| marking is supported.
| Nodes from different vendors have different metering 
| capabilities with metering (token bucket) being most common 
| on incoming or ingress interfaces. At lest, I believe that 
| the PCN architecture should provide freedom were vendor 
| implements the PCN metering and marking function.
| Should point out it will also depend on what method the 
| vendor chooses to use for metering. If a token bucket 
| approach is used than a common place would be ingress 
| interface but if virtual queue approach is used than maybe 
| egress interface would be the place. A vendor may also 
| implement PCN metering and marking on both ingress and egress 
| interfaces of a node therefore providing support for PCN on 
| links to and from the node.
| 
| 
| More details below. Please note that if I didn't comment a 
| change you've proposed, this doesn't indicate agreement. Some 
| of your comments aren't easy to understand for me.
| 
| Regards,
| 
| Ruediger
| 
| 
| 
|  
| Terminology
|  
| [JB]: PCN-domain: a PCN-capable domain; a contiguous set of 
| PCN-enabled nodes that provide the PCN function to at least 
| one traffic class that is DiffServ scheduling;
| 
| [RG] if this needs to be changed, what about:
| ...PCN-enabled nodes perfoming DiffServ scheduling with PCN 
| functionality to the PCN coloured traffic..
| [Joe] I'm OK with above, but would deleted word *coloured*.
| 
| ------
| 
| [JB]: PCN-boundary-node: a PCN-node that connects one 
| PCN-domain to a node either in another PCN-domain or in a non 
| PCN-domain.
| 
| PCN-edge-node: a node that is at ingress or egress point to 
| the PCN-enabled network. Traffic entering or leaving the PCN 
| network passes through it.
| Note,
| PCN-boundary-node is a special case of PCN-edge-node.
| 
| [RG]: I don't understand why the terminology is changed in 
| the stage we have reached. Has this been agreed in Vancouver? 
| I also don't understand the difference between the definitons.
| [Joe]My confusion, after reading definition for DS Boundary 
| node in RFC2475, I'm OK with using PCN-boundary-node. Please 
| add reference to
| RFC2475 Section 2.1.1 as definition of boundary-node.
| 
| -------
| 
| 3.1. Assumption 1: Trust and support of PCN function - 
| controlled environment
| 
| [JB]: o Similarly, a PCN-edge-node has to trust that all the 
| PCN-nodes mark PCN traffic consistently. A link within the 
| PCN-domain wouldn't be able to alert...
| 
| [RG]: The original sentence "A non-PCN-node within the PCN-domain..."
| should
| be used. Links aren't able to alert anyway, PCN is a node or 
| interface function. This comment applies to all insertions of 
| "links" following in
| 
| this paragraph.
| [Joe]How about. "A node performing PCN metering and marking 
| within the PCN-domain 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)."

*
[RG] Allright with me.
*
 
| -------
| 
| 3.3. Assumption 3: Many flows and additional load
| 
| [JB]: We do not make explicit assumptions on how many 
| PCN-flows are on each bottleneck link. Performance evaluation 
| work may clarify whether it is necessary to make any 
| additional assumption on aggregation on the bottleneck link.
| 
| [RG]: This section should stay like it was and discuss the 
| PCN assumptions on ingress-egress aggregates. Our assumptions 
| on aggregation on links are discussed in the preceding 
| section and any necessary changes regarding link aggregation 
| should be added there.
| [Joe] My interpolation is that Assumption 3 is about 
| aggregate at the point where the PCN metering and marking 
| function is performed and not how many flows belong to an 
| ingress-egress aggregate. These are different issues.  
| 

*
[RG] I understand your comment and your point of view, I think. 
"The original text referring to ingress-egress aggregates 
doesn't fit to this section" is what you say, isn't it? This 
is because this section is limited to traffic conditions at 
marking and metering nodes.
The remark about ingress egress aggregates may better fit to 
e.g. section 4. The assumptions and relevance we make on 
ingress egress aggregates needs to stay in the  draft, but 
you are right that this doesn't fit well to 3.3.

End of my comments in this mail
*

| ---------
| 
| 4.1. Flow admission
| 
| [JB]the algorithm: a PCN-node meters the amount of 
| PCN-traffic on a link (on its incoming or outgoing links). 
| The measurement is made as an aggregate of all PCN-packets on 
| that link, and not per flow.
| 
| [RG]: please change to
| .... on each of its incoming or outgoing links...
| and leave the orinial text: ...on each one of its links, and not...
| If it should be emphasised that this is done per link aggregate:
| ...on each single one of its links, and not..
| 
| ________________________________
| 
| 	Von: Jozef Babiarz [mailto:[email-masked]] 
| 	Gesendet: Dienstag, 1. Januar 2008 21:03
| 	An: PCN IETF
| 	Betreff: [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-0
| 2-jb.doc>
| 
| 
| 	
| http://standards.nortel.com/pcn/draft-ietf-pcn-architecture-02-jb.pdf
| <http://standards.nortel.com/pcn/draft-ietf-pcn-architecture-0
| 2-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

---

From: "Jozef Babiarz" <[email-masked]>
Date: Sun, 3 Feb 2008 23:11:35 -0500

Phil, 

I'm OK with PCN-boundary-node as long as we use the definition of
boundary-node as in RFC2475 Section 2.1.1 and add the PCN stuff to it.

The reason why I'm suggesting that "aggregated" be deleted because in
those parts it's not needed. The interior-nodes have no view of number
of flows.

At the PCN-egress node, there are two approaches to measure or detect
level of pre-congestion, one approach is to measure rate of marked or
unmarked traffic and with this approach the level of ingress-egress
aggregation is impotent. The second approach is to simply look at the
marking and report it to ingress or the centralized entity, which does
not have any dependency on level of ingress-egress aggregation. I think
the architecture draft should be written so it can accommodate both
approaches. 

Yes, S5 were the last changes that I sent you.

Regards, Joe 
email:[email-masked] 
Telephone:613-763-6098 

________________________________

From: [email-masked] [mailto:[email-masked]] 
Sent: January 29, 2008 7:28 AM
To: Babiarz, Jozef (CAR:0S03); [email-masked]
Subject: RE: [PCN] Review of pcn-architecture-02 draft

Joe

I'm now updating the architecture draft. Thanks for your comments!

Some initial questions:

- you used the term 'PCN-edge-node' (rather than PCN-boundary-node) with
a new definition. I didn't understand why - in particular I didn't
understand what the substantive difference is between the 2 definitions

- in the abstract, you changed "..architecture for flow admission and
termination based on aggregated pre-congestion information..." by
deleting "aggregated". You also made similar change at several places in
the doc, eg possibility of PCN-egress-node making measurements per flow
(rather than per aggregate). My proposal: to leave the draft as it is,
however there'll be a new section called something like "Beyond the
current PCN charter" where I'll mention the per flow stuff. Steve Blake
recommended (off list) to have such a section, and I'm going to move all
the comments about charter scope to this new section. I think your per
flow stuff will fit best there.

Stokes, Deborah (RICH2:1A00) 

More later

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

---

From: Lars Eggert <[email-masked]>
Date: Mon, 4 Feb 2008 10:33:32 +0200

> those parts it's not needed. The interior-nodes have no view of number

And that's why the mechanisms operate on aggregated information,  
rather than on per-flow information. PCN is all about marking volume  
vs. traffic volume - no decisions are made based on individual flow  
characteristics.

Lars

---

From: <[email-masked]>
Date: Mon, 4 Feb 2008 14:27:49 -0000

Yes, the interior nodes only know about aggregated traffic. The
architecture draft is clear, eg S1:   o  The PCN-marking behaviours only
operate on the overall PCN-traffic on the link, not per flow.

Yes, edge nodes (potentially) can base admission/termination decisions
on aggregated traffic or an individual flow, based on the PCN marked
pkts they see. The architecture draft tries to outline both
possibilities. In the update I'm working on, I've tried to do some minor
mods in a few places, on the lines you suggested Joe (in your edited doc
on the Nortel website). 

Phil/

> From: Lars Eggert [mailto:[email-masked]]
> Sent: 04 February 2008 08:34
> To: ext Jozef Babiarz
> Cc: Eardley,PL,Philip,CXR9 R; [email-masked]
> Subject: Re: [PCN] Review of pcn-architecture-02 draft
>

---

From: <[email-masked]>
Date: Thu, 7 Feb 2008 15:50:06 -0000

I've found the simplest way of handling this interfaces vs links
question is to add the following para near the start of section 4:

Note: Section 4 and Section 5 talk about PCN functionality being
configured on outgoing interfaces of PCN-nodes. Alternatively,
PCN-functionality could be configured on the ingress interfaces of
PCN-nodes, however a consistence choice must be made across the
PCN-domain to ensure that the PCN mechanisms protect all links. This
document assumes configuration on the egress interfaces, because in
DiffServ networks today DiffServ functionality is usually implemented on
egress interfaces.

Otherwise I've left the text unaltered. 
As Ruediger pointed out, this means that the doc sometimes talks about
links and sometimes interfaces. I don't think this is too unreasonable -
in S4 & S5 (high level & detailed architecture) talk about configuring
functionality on an interface - since the focus in S4/5 is what would
actually be done. whereas in the other sections, we're really
introducing the idea of PCn, explaining issues etc - then it seems ok to
talk about pre-congestion on links, since that makes phrasing
(/thinking) simpler.

Hope this is ok & you don't think I cheated too much

phil

> Sent: 17 January 2008 10:34
> To: [email-masked]; [email-masked]
> Hi Joe,
> some comments on your comments:
> 
> One general remark is whether we should talk of "interfaces" (instead
> of links) whenever PCN node-functionalities are addressed. Up to now,
> there's a mix in the text.
> 
> You introduce the concept of PCN functionality on either incoming or
> outgoing interfaces. PCN doesn't work, if there's a sequence of nodes
> 
> Node1: outgoing IF - Node 2: incoming IF - Node 3: outgoing IF,
> 
> there's a link between node 2 and 3 without PCN functionality on
> any interface. So a domain shouldn't mix these nodes. I'd prefer
> PCN functionality on outgoing IF's, if this is closer to todays
> DiffServ implementations.
> 
> More details below. Please note that if I didn't comment a change
> you've proposed, this doesn't indicate agreement. Some of your
> comments aren't easy to understand for me.
> 
> Regards,
> 
> Ruediger
> 
> 
> 
> 
> Terminology
> 
> [JB]: PCN-domain: a PCN-capable domain; a contiguous set of
PCN-enabled
> nodes that provide the PCN function to at least one traffic class that
is
> DiffServ scheduling;
> 
> [RG] if this needs to be changed, what about:
> ...PCN-enabled nodes perfoming DiffServ scheduling with PCN
functionality
> to the PCN coloured traffic..
> 
> ------
> 
> [JB]: PCN-boundary-node: a PCN-node that connects one PCN-domain to a
> node either in another PCN-domain or in a non PCN-domain.
> 
> PCN-edge-node: a node that is at ingress or egress point to the PCN-
> enabled
> network. Traffic entering or leaving the PCN network passes through
it.
> Note,
> PCN-boundary-node is a special case of PCN-edge-node.
> 
> [RG]: I don't understand why the terminology is changed in the stage
we
> have
> reached. Has this been agreed in Vancouver? I also don't understand
the
> difference between the definitons.
> 
> -------
> 
> 3.1. Assumption 1: Trust and support of PCN function - controlled
> environment
> 
> [JB]: o Similarly, a PCN-edge-node has to trust that all the PCN-nodes
> mark PCN traffic consistently. A link within the PCN-domain wouldn't
be
> able to alert...
> 
> [RG]: The original sentence "A non-PCN-node within the PCN-domain..."
> should
> be used. Links aren't able to alert anyway, PCN is a node or interface
> function. This comment applies to all insertions of "links" following
in
> this paragraph.
> 
> -------
> 
> 3.3. Assumption 3: Many flows and additional load
> 
> [JB]: We do not make explicit assumptions on how many PCN-flows are on
> each
> bottleneck link. Performance evaluation work may clarify
> whether it is necessary to make any additional assumption on
> aggregation on the bottleneck link.
> 
> [RG]: This section should stay like it was and discuss the PCN
assumptions
> on ingress-egress aggregates. Our assumptions on aggregation on links
are
> discussed in the preceding section and any necessary changes regarding
> link
> aggregation should be added there.
> 
> ---------
> 
> 4.1. Flow admission
> 
> [JB]the algorithm: a PCN-node meters the amount of PCN-traffic on
> a link (on its incoming or outgoing links). The measurement is made
> as an aggregate of all PCN-packets on that link, and not per flow.
> 
> [RG]: please change to
> .... on each of its incoming or outgoing links...
> and leave the orinial text: ...on each one of its links, and not...
> If it should be emphasised that this is done per link aggregate:
> ...on each single one of its links, and not..
> 
> 	Von: Jozef Babiarz [mailto:[email-masked]]
> 	Gesendet: Dienstag, 1. Januar 2008 21:03
> 	An: PCN IETF
> 	Betreff: [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.pdf>
Field.
> 	I will send comments on remaining of the draft, Section 6 to end
in
> few days.
> https://www1.ietf.org/mailman/listinfo/pcn

---

From: "Geib, Ruediger" <[email-masked]>
Date: Thu, 7 Feb 2008 17:10:48 +0100

Phil,

both proposals are allright with me.

Regards,

Ruediger

| -----Original Message-----
| From: [email-masked] [mailto:[email-masked]] 
| Sent: Thursday, February 07, 2008 4:50 PM
| To: Geib, Rüdiger; [email-masked]; [email-masked]
| Subject: RE: [PCN] Review of pcn-architecture-02 draft
| 
| I've found the simplest way of handling this interfaces vs 
| links question is to add the following para near the start of 
| section 4:
| 
| Note: Section 4 and Section 5 talk about PCN functionality 
| being configured on outgoing interfaces of PCN-nodes. 
| Alternatively, PCN-functionality could be configured on the 
| ingress interfaces of PCN-nodes, however a consistence choice 
| must be made across the PCN-domain to ensure that the PCN 
| mechanisms protect all links. This document assumes 
| configuration on the egress interfaces, because in DiffServ 
| networks today DiffServ functionality is usually implemented 
| on egress interfaces.
| 
| Otherwise I've left the text unaltered. 
| As Ruediger pointed out, this means that the doc sometimes 
| talks about links and sometimes interfaces. I don't think 
| this is too unreasonable - in S4 & S5 (high level & detailed 
| architecture) talk about configuring functionality on an 
| interface - since the focus in S4/5 is what would actually be 
| done. whereas in the other sections, we're really introducing 
| the idea of PCn, explaining issues etc - then it seems ok to 
| talk about pre-congestion on links, since that makes phrasing
| (/thinking) simpler.
| 
| Hope this is ok & you don't think I cheated too much
| 
| phil
| 
| > -----Original Message-----
| > From: Geib, Ruediger [mailto:[email-masked]]
| > Sent: 17 January 2008 10:34
| > To: [email-masked]; [email-masked]
| > Subject: AW: [PCN] Review of pcn-architecture-02 draft
| > 
| > Hi Joe,
| > 
| > some comments on your comments:
| > 
| > One general remark is whether we should talk of 
| "interfaces" (instead 
| > of links) whenever PCN node-functionalities are addressed. 
| Up to now, 
| > there's a mix in the text.
| > 
| > You introduce the concept of PCN functionality on either 
| incoming or 
| > outgoing interfaces. PCN doesn't work, if there's a 
| sequence of nodes
| > 
| > Node1: outgoing IF - Node 2: incoming IF - Node 3: outgoing IF,
| > 
| > there's a link between node 2 and 3 without PCN 
| functionality on any 
| > interface. So a domain shouldn't mix these nodes. I'd prefer PCN 
| > functionality on outgoing IF's, if this is closer to todays 
| DiffServ 
| > implementations.
| > 
| > More details below. Please note that if I didn't comment a change 
| > you've proposed, this doesn't indicate agreement. Some of your 
| > comments aren't easy to understand for me.
| > 
| > Regards,
| > 
| > Ruediger
| > 
| > 
| > 
| > 
| > Terminology
| > 
| > [JB]: PCN-domain: a PCN-capable domain; a contiguous set of
| PCN-enabled
| > nodes that provide the PCN function to at least one traffic 
| class that
| is
| > DiffServ scheduling;
| > 
| > [RG] if this needs to be changed, what about:
| > ...PCN-enabled nodes perfoming DiffServ scheduling with PCN
| functionality
| > to the PCN coloured traffic..
| > 
| > ------
| > 
| > [JB]: PCN-boundary-node: a PCN-node that connects one 
| PCN-domain to a 
| > node either in another PCN-domain or in a non PCN-domain.
| > 
| > PCN-edge-node: a node that is at ingress or egress point to 
| the PCN- 
| > enabled network. Traffic entering or leaving the PCN network passes 
| > through
| it.
| > Note,
| > PCN-boundary-node is a special case of PCN-edge-node.
| > 
| > [RG]: I don't understand why the terminology is changed in the stage
| we
| > have
| > reached. Has this been agreed in Vancouver? I also don't understand
| the
| > difference between the definitons.
| > 
| > -------
| > 
| > 3.1. Assumption 1: Trust and support of PCN function - controlled 
| > environment
| > 
| > [JB]: o Similarly, a PCN-edge-node has to trust that all 
| the PCN-nodes 
| > mark PCN traffic consistently. A link within the PCN-domain wouldn't
| be
| > able to alert...
| > 
| > [RG]: The original sentence "A non-PCN-node within the 
| PCN-domain..."
| > should
| > be used. Links aren't able to alert anyway, PCN is a node 
| or interface 
| > function. This comment applies to all insertions of "links" 
| following
| in
| > this paragraph.
| > 
| > -------
| > 
| > 3.3. Assumption 3: Many flows and additional load
| > 
| > [JB]: We do not make explicit assumptions on how many 
| PCN-flows are on 
| > each bottleneck link. Performance evaluation work may 
| clarify whether 
| > it is necessary to make any additional assumption on aggregation on 
| > the bottleneck link.
| > 
| > [RG]: This section should stay like it was and discuss the PCN
| assumptions
| > on ingress-egress aggregates. Our assumptions on 
| aggregation on links
| are
| > discussed in the preceding section and any necessary 
| changes regarding 
| > link aggregation should be added there.
| > 
| > ---------
| > 
| > 4.1. Flow admission
| > 
| > [JB]the algorithm: a PCN-node meters the amount of PCN-traffic on a 
| > link (on its incoming or outgoing links). The measurement 
| is made as 
| > an aggregate of all PCN-packets on that link, and not per flow.
| > 
| > [RG]: please change to
| > .... on each of its incoming or outgoing links...
| > and leave the orinial text: ...on each one of its links, and not...
| > If it should be emphasised that this is done per link aggregate:
| > ...on each single one of its links, and not..
| > 
| > ________________________________
| > 
| > 	Von: Jozef Babiarz [mailto:[email-masked]]
| > 	Gesendet: Dienstag, 1. Januar 2008 21:03
| > 	An: PCN IETF
| > 	Betreff: [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]
| > https://www1.ietf.org/mailman/listinfo/pcn
| 
_______________________________________________
PCN mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/pcn