Subject: [PCN] Fw: draft-eardley-pcn-marking-behaviour-00

From: "Wei Gengyu" <[email-masked]>
Date: Wed, 18 Jun 2008 01:09:11 +0800

----- Original Message ----- 
From: "Wei Gengyu" <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, June 17, 2008 10:41 PM
Subject: Re: [PCN] draft-eardley-pcn-marking-behaviour-00

> Philip,
>
> For the first question, your I-D in Section 2.1 is clear as you said.
> I got it after reading your explanations. Thank you.
>
> But, I still think it may be better to make 3-states nodes compatible with 
> 2-states node.
> Consider the case, if a PCN domain covers more than one autonomous domain 
> in the Internet,
> the mechanism in sechtion 2.1 could not tolerate any configuration faults.
>
> So, if the PCN domain can works in 2-states scheme when there are both 
> 2-state and 3state nodes,
> loosely-consistent checking is required in a PCN domain.
>
> As clarification of nodes across several autonomous domains may not be as 
> easy as MTU discovery,
> having the marking info compatible is probably better than making encoding 
> choice the same in all PCN links.
>
> Your comments?
>
> Regards,
>
> Gengyu
> School of Computer Science and Technology
> Beijing University of Posts and Telecommunications
>
> ----- Original Message ----- 
> From: <[email-masked]>
> To: <[email-masked]>
> Cc: <[email-masked]>
> Sent: Tuesday, June 17, 2008 6:14 PM
> Subject: RE: [PCN] draft-eardley-pcn-marking-behaviour-00
>
>
> Gengyu
>
> Thanks very much for your comments!
>
> 1) I think this is covered in Section 2.1 (Scope), which states "The
> same choice MUST be used throughout a PCN-domain." - this refers to the
> same choice about encoding states in all the PCN links in the domain.
>
> In your example you have a node with 2 encoding states in the same
> domain as nodes with 3 encoding states. Therefore the example breaks the
> "MUST" in Section 2.1, ie the domain is misconfigured (and so strictly
> speaking it isn't a PCN domain, so we don't need to worry about it).
>
> If you've a suggestion how to clarify this, please let me know.
>
> 2) if I understand you right, you're suggesting that when a link is
> pre-congested, it sends a message (instead of marking packets). Yes,
> this is a possible approach, but - as you say - it's out of scope of
> PCN.
>
> thanks
> phil
>
> { -----Original Message-----
> { From: Wei Gengyu [mailto:[email-masked]]
> { Sent: 17 June 2008 10:39
> { To: Eardley,PL,Philip,CXR9 R
> { Cc: [email-masked]
> { Subject: Re: [PCN] draft-eardley-pcn-marking-behaviour-00
> {
> { Hi,
> {
> { I have some questions to ask after reading your I-D.
> {
> { 1) In a PCN domain, if the two-state node is between two three-states
> { nodes,
> { how the marking scheme will be?
> {    So is it ture if there is a two-state node along the route, that
> will
> { be
> { two-state scheme.
> {    This is important for a network administrator.
> { 2) In section 2.2.  Classify and condition function
> {    "There may be traffic that is more important than PCN that shares
> the
> {    same capacity as PCN and is priority scheduled over PCN (perhaps an
> {    operator's control messages).  Such traffic MUST be metered as
> though
> {    it were PCN-traffic, but MUST NOT be PCN-marked.  Such packets,
> {    together with PCN-packets, are called "metered packets"."
> {
> {    You mentioned the packet which contains an operator's control
> messages,
> { so my question is if the marking contexts are sent in control
> messages,
> { or PCN-capable nodes at ingress generat control messages when sending
> { marks,
> { what the pcn will be?
> { Perhaps the second question is out of the scope of PCN,
> { but there was some schemes in ATM to send RM cell instead of marking
> each
> { cell.
> {
> { Regards,
> {
> { Gengyu
> {
> 

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

---

From: <[email-masked]>
Date: Wed, 18 Jun 2008 09:18:58 +0100

Gengyu,

You raise interesting questions. I'm not really sure what compatibility
means in this context - it would probably need some careful thought and
simulations /expts to work out if it could be compatible to some extent.
I'm not sure a similar mechanism to MTU discovery would be appropriate -
the number of encoding states in nodes in a PCN-domain really is
something that the operator of that domain ought to know - it doesn't
seem to me that this is a good thing to discover dynamically.

I think we should remember rudiger's warning when we got into discussing
configuration issues before - it isn't our job to make sure everything
behaves properly if something is configured incorrectly

Best wishes
Phil 

{ -----Original Message-----
{ From: [email-masked] [mailto:[email-masked]] On Behalf Of
Wei
{ Gengyu
{ Sent: 17 June 2008 18:09
{ To: [email-masked]
{ Subject: [PCN] Fw: draft-eardley-pcn-marking-behaviour-00
{ 
{ 
{ ----- Original Message -----
{ From: "Wei Gengyu" <[email-masked]>
{ To: <[email-masked]>
{ Sent: Tuesday, June 17, 2008 10:41 PM
{ Subject: Re: [PCN] draft-eardley-pcn-marking-behaviour-00
{ 
{ 
{ > Philip,
{ >
{ > For the first question, your I-D in Section 2.1 is clear as you
said.
{ > I got it after reading your explanations. Thank you.
{ >
{ > But, I still think it may be better to make 3-states nodes
compatible
{ with
{ > 2-states node.
{ > Consider the case, if a PCN domain covers more than one autonomous
{ domain
{ > in the Internet,
{ > the mechanism in sechtion 2.1 could not tolerate any configuration
{ faults.
{ >
{ > So, if the PCN domain can works in 2-states scheme when there are
both
{ > 2-state and 3state nodes,
{ > loosely-consistent checking is required in a PCN domain.
{ >
{ > As clarification of nodes across several autonomous domains may not
be
{ as
{ > easy as MTU discovery,
{ > having the marking info compatible is probably better than making
{ encoding
{ > choice the same in all PCN links.
{ >
{ > Your comments?
{ >
{ > Regards,
{ >
{ > Gengyu
{ > School of Computer Science and Technology
{ > Beijing University of Posts and Telecommunications
{ >
{ > ----- Original Message -----
{ > From: <[email-masked]>
{ > To: <[email-masked]>
{ > Cc: <[email-masked]>
{ > Sent: Tuesday, June 17, 2008 6:14 PM
{ > Subject: RE: [PCN] draft-eardley-pcn-marking-behaviour-00
{ >
{ >
{ > Gengyu
{ >
{ > Thanks very much for your comments!
{ >
{ > 1) I think this is covered in Section 2.1 (Scope), which states "The
{ > same choice MUST be used throughout a PCN-domain." - this refers to
the
{ > same choice about encoding states in all the PCN links in the
domain.
{ >
{ > In your example you have a node with 2 encoding states in the same
{ > domain as nodes with 3 encoding states. Therefore the example breaks
the
{ > "MUST" in Section 2.1, ie the domain is misconfigured (and so
strictly
{ > speaking it isn't a PCN domain, so we don't need to worry about it).
{ >
{ > If you've a suggestion how to clarify this, please let me know.
{ >
{ > 2) if I understand you right, you're suggesting that when a link is
{ > pre-congested, it sends a message (instead of marking packets). Yes,
{ > this is a possible approach, but - as you say - it's out of scope of
{ > PCN.
{ >
{ > thanks
{ > phil
{ >
{ > { -----Original Message-----
{ > { From: Wei Gengyu [mailto:[email-masked]]
{ > { Sent: 17 June 2008 10:39
{ > { To: Eardley,PL,Philip,CXR9 R
{ > { Cc: [email-masked]
{ > { Subject: Re: [PCN] draft-eardley-pcn-marking-behaviour-00
{ > {
{ > { Hi,
{ > {
{ > { I have some questions to ask after reading your I-D.
{ > {
{ > { 1) In a PCN domain, if the two-state node is between two
three-states
{ > { nodes,
{ > { how the marking scheme will be?
{ > {    So is it ture if there is a two-state node along the route,
that
{ > will
{ > { be
{ > { two-state scheme.
{ > {    This is important for a network administrator.
{ > { 2) In section 2.2.  Classify and condition function
{ > {    "There may be traffic that is more important than PCN that
shares
{ > the
{ > {    same capacity as PCN and is priority scheduled over PCN
(perhaps an
{ > {    operator's control messages).  Such traffic MUST be metered as
{ > though
{ > {    it were PCN-traffic, but MUST NOT be PCN-marked.  Such packets,
{ > {    together with PCN-packets, are called "metered packets"."
{ > {
{ > {    You mentioned the packet which contains an operator's control
{ > messages,
{ > { so my question is if the marking contexts are sent in control
{ > messages,
{ > { or PCN-capable nodes at ingress generat control messages when
sending
{ > { marks,
{ > { what the pcn will be?
{ > { Perhaps the second question is out of the scope of PCN,
{ > { but there was some schemes in ATM to send RM cell instead of
marking
{ > each
{ > { cell.
{ > {
{ > { Regards,
{ > {
{ > { Gengyu
{ > {
{ >
{ 
{ _______________________________________________
{ PCN mailing list
{ [email-masked]
{ https://www.ietf.org/mailman/listinfo/pcn
_______________________________________________
PCN mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pcn

---

From: "Wei Gengyu" <[email-masked]>
Date: Wed, 18 Jun 2008 20:08:30 +0800

Phil, and all,

I strongly suggest PCN WG review the coding scheme.
It is not good to have two exclusive coding algorithms in one technical 
document.

It is easy to see that 3-states have more information than 2-states.
It is also possible to make 2-states be the subset of three states.
The compatibility here means 3-state capability nodes can understand 2-state 
coding.

I did not suggest to use MTU discovery or similar mechanisms for node 
clarification, neither do here.

While remembering rudiger's words, we should face the existing problems of 
networks.
The operator ought to knwo the nodes within its own dommains.
But, it is rather difficult for any operators to know the nodes of other 
autonomous nodes
if a PCN domain covers several autonomous domains.

I believe, it will be better if the PCN coding schemes is easy to deploy,
robust to work, and tolerant of faults.

We do not need to make sure everything properly,
we only need to make 2-state capable nodes work togather with 3-state 
capable nodes.

Regards,

Gengyu

----- Original Message ----- 
From: <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Sent: Wednesday, June 18, 2008 4:18 PM
Subject: RE: [PCN] Fw: draft-eardley-pcn-marking-behaviour-00

Gengyu,

Best wishes
Phil

---

From: <[email-masked]>
Date: Wed, 18 Jun 2008 13:42:11 +0100

I think I may be confusing things unnecessarily.

The encoding proposal from Toby & Michael et al is structured as
follows:
- a baseline encoding. This uses 1 (standardised) DSCP + the ECN
codepoints in order to encode 2 states.
- an extension encoding. This uses a second DSCP (in addition to the
baseline's DSCP) + the ECN codepoints and encodes 3 states. 

The use of the ECN codepoints is compatible between them, in the sense
that eg ECN 11 means some form of PCN marking in all cases - it was a
deliberate choice to do it like this (So you could say that the 2
encoding states are a sub-set of the 3 encoding states - which is one of
your requirements)

The baseline has already been sent to the list
http://tools.ietf.org/id/draft-moncaster-pcn-baseline-encoding-00.txt
- toby plans to send the extension draft soon (a draft is being reviewed
amongst the authors)

I think in your example you envisage 2 separate networks both running
PCN which then later get merged into a single PCN-domain. So you have
one with 2 encoding states & one with 3 encoding states (or indeed: both
have 2 encoding states, but one is using them to trigger admission
control and one termination control, relying on other mechanisms for the
other function, or one is using the marks to trigger both admission &
termination - ie 'single marking'). As well as the pure encoding, then
there'll be other things to think about - eg the ingress & egress
gateways can be in different domains and so will interpret the received
marks differently. Personally I think it's reasonable to expect
"management" to have to be done when the 2 separate nws are joined
together to form a single PCN-domain - ie to coordinate how PCN marks
will be interpreted. I don't know whether something clever can be done
that doesn't require such work - maybe it would make a good topic to
discuss over lunch, if you're in Dublin? (I think this kind of
discussion on 'forming a single PCN domain from two separate PCN
domains' probably falls into the inter-domain category, which is out of
scope of PCN WG in initial charter.)

Thanks
phil

{ -----Original Message-----
{ From: Wei Gengyu [mailto:[email-masked]]
{ Sent: 18 June 2008 13:09
{ To: Eardley,PL,Philip,CXR9 R
{ Cc: [email-masked]
{ Subject: Re: [PCN] Fw: draft-eardley-pcn-marking-behaviour-00
{ 
{ Phil, and all,
{ 
{ I strongly suggest PCN WG review the coding scheme.
{ It is not good to have two exclusive coding algorithms in one
technical
{ document.
{ 
{ It is easy to see that 3-states have more information than 2-states.
{ It is also possible to make 2-states be the subset of three states.
{ The compatibility here means 3-state capability nodes can understand
2-
{ state
{ coding.
{ 
{ I did not suggest to use MTU discovery or similar mechanisms for node
{ clarification, neither do here.
{ 
{ While remembering rudiger's words, we should face the existing
problems of
{ networks.
{ The operator ought to knwo the nodes within its own dommains.
{ But, it is rather difficult for any operators to know the nodes of
other
{ autonomous nodes
{ if a PCN domain covers several autonomous domains.
{ 
{ I believe, it will be better if the PCN coding schemes is easy to
deploy,
{ robust to work, and tolerant of faults.
{ 
{ We do not need to make sure everything properly,
{ we only need to make 2-state capable nodes work togather with 3-state
{ capable nodes.
{ 
{ Regards,
{ 
{ Gengyu
{ 
{ 
{ ----- Original Message -----
{ From: <[email-masked]>
{ To: <[email-masked]>; <[email-masked]>
{ Sent: Wednesday, June 18, 2008 4:18 PM
{ Subject: RE: [PCN] Fw: draft-eardley-pcn-marking-behaviour-00
{ 
{ 
{ Gengyu,
{ 
{ You raise interesting questions. I'm not really sure what
compatibility
{ means in this context - it would probably need some careful thought
and
{ simulations /expts to work out if it could be compatible to some
extent.
{ I'm not sure a similar mechanism to MTU discovery would be appropriate
-
{ the number of encoding states in nodes in a PCN-domain really is
{ something that the operator of that domain ought to know - it doesn't
{ seem to me that this is a good thing to discover dynamically.
{ 
{ I think we should remember rudiger's warning when we got into
discussing
{ configuration issues before - it isn't our job to make sure everything
{ behaves properly if something is configured incorrectly
{ 
{ Best wishes
{ Phil
{ 
{ { -----Original Message-----
{ { From: [email-masked] [mailto:[email-masked]] On Behalf
Of
{ Wei
{ { Gengyu
{ { Sent: 17 June 2008 18:09
{ { To: [email-masked]
{ { Subject: [PCN] Fw: draft-eardley-pcn-marking-behaviour-00
{ {
{ {
{ { ----- Original Message -----
{ { From: "Wei Gengyu" <[email-masked]>
{ { To: <[email-masked]>
{ { Sent: Tuesday, June 17, 2008 10:41 PM
{ { Subject: Re: [PCN] draft-eardley-pcn-marking-behaviour-00
{ {
{ {
{ { > Philip,
{ { >
{ { > For the first question, your I-D in Section 2.1 is clear as you
{ said.
{ { > I got it after reading your explanations. Thank you.
{ { >
{ { > But, I still think it may be better to make 3-states nodes
{ compatible
{ { with
{ { > 2-states node.
{ { > Consider the case, if a PCN domain covers more than one autonomous
{ { domain
{ { > in the Internet,
{ { > the mechanism in sechtion 2.1 could not tolerate any configuration
{ { faults.
{ { >
{ { > So, if the PCN domain can works in 2-states scheme when there are
{ both
{ { > 2-state and 3state nodes,
{ { > loosely-consistent checking is required in a PCN domain.
{ { >
{ { > As clarification of nodes across several autonomous domains may
not
{ be
{ { as
{ { > easy as MTU discovery,
{ { > having the marking info compatible is probably better than making
{ { encoding
{ { > choice the same in all PCN links.
{ { >
{ { > Your comments?
{ { >
{ { > Regards,
{ { >
{ { > Gengyu
{ { > School of Computer Science and Technology
{ { > Beijing University of Posts and Telecommunications
{ { >
{ { > ----- Original Message -----
{ { > From: <[email-masked]>
{ { > To: <[email-masked]>
{ { > Cc: <[email-masked]>
{ { > Sent: Tuesday, June 17, 2008 6:14 PM
{ { > Subject: RE: [PCN] draft-eardley-pcn-marking-behaviour-00
{ { >
{ { >
{ { > Gengyu
{ { >
{ { > Thanks very much for your comments!
{ { >
{ { > 1) I think this is covered in Section 2.1 (Scope), which states
"The
{ { > same choice MUST be used throughout a PCN-domain." - this refers
to
{ the
{ { > same choice about encoding states in all the PCN links in the
{ domain.
{ { >
{ { > In your example you have a node with 2 encoding states in the same
{ { > domain as nodes with 3 encoding states. Therefore the example
breaks
{ the
{ { > "MUST" in Section 2.1, ie the domain is misconfigured (and so
{ strictly
{ { > speaking it isn't a PCN domain, so we don't need to worry about
it).
{ { >
{ { > If you've a suggestion how to clarify this, please let me know.
{ { >
{ { > 2) if I understand you right, you're suggesting that when a link
is
{ { > pre-congested, it sends a message (instead of marking packets).
Yes,
{ { > this is a possible approach, but - as you say - it's out of scope
of
{ { > PCN.
{ { >
{ { > thanks
{ { > phil
{ { >
{ { > { -----Original Message-----
{ { > { From: Wei Gengyu [mailto:[email-masked]]
{ { > { Sent: 17 June 2008 10:39
{ { > { To: Eardley,PL,Philip,CXR9 R
{ { > { Cc: [email-masked]
{ { > { Subject: Re: [PCN] draft-eardley-pcn-marking-behaviour-00
{ { > {
{ { > { Hi,
{ { > {
{ { > { I have some questions to ask after reading your I-D.
{ { > {
{ { > { 1) In a PCN domain, if the two-state node is between two
{ three-states
{ { > { nodes,
{ { > { how the marking scheme will be?
{ { > {    So is it ture if there is a two-state node along the route,
{ that
{ { > will
{ { > { be
{ { > { two-state scheme.
{ { > {    This is important for a network administrator.
{ { > { 2) In section 2.2.  Classify and condition function
{ { > {    "There may be traffic that is more important than PCN that
{ shares
{ { > the
{ { > {    same capacity as PCN and is priority scheduled over PCN
{ (perhaps an
{ { > {    operator's control messages).  Such traffic MUST be metered
as
{ { > though
{ { > {    it were PCN-traffic, but MUST NOT be PCN-marked.  Such
packets,
{ { > {    together with PCN-packets, are called "metered packets"."
{ { > {
{ { > {    You mentioned the packet which contains an operator's control
{ { > messages,
{ { > { so my question is if the marking contexts are sent in control
{ { > messages,
{ { > { or PCN-capable nodes at ingress generat control messages when
{ sending
{ { > { marks,
{ { > { what the pcn will be?
{ { > { Perhaps the second question is out of the scope of PCN,
{ { > { but there was some schemes in ATM to send RM cell instead of
{ marking
{ { > each
{ { > { cell.
{ { > {
{ { > { Regards,
{ { > {
{ { > { Gengyu
{ { > {
{ { >
{ {
{ { _______________________________________________
{ { PCN mailing list
{ { [email-masked]
{ { https://www.ietf.org/mailman/listinfo/pcn

---

From: "Wei Gengyu" <[email-masked]>
Date: Fri, 20 Jun 2008 01:04:44 +0800

Phil,

I am not in Dublin, but I like to drink red tea while disscussing the 
technical issues with my collegues.
The network we often concern is the network that covers an area greater than 
an island.

Consider the case, a university with serveral campus located at different 
cities,
it is one unversity network of a collection of campus networks.
Or the network of an enterprises with serveral branches located in different 
states is one network.
Those are truely existed networks nowadays.

And having experiences as a network administor will be helpful to decide how 
to configure a network
and to understand the problem of coding schemes.

In your email you described the problem and the node behavior clearly.
I do think that the problems must be solved.

In my opinion,the problems are due to the semantics of 2-state and 3-state 
coding schemes.
So, I argue that the WG should review coding schemes.

Regards,

Gengyu

----- Original Message ----- 
From: <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, June 18, 2008 8:42 PM
Subject: RE: [PCN] Fw: draft-eardley-pcn-marking-behaviour-00

Thanks
phil

---

From: "Geib, Ruediger" <[email-masked]>
Date: Fri, 20 Jun 2008 16:37:04 +0200

Gengyu,

the two state issue may specifically be relevant for carriers working with MPLS. Inter carrier MPLS services are possible, but still I doubt that there are many carriers operating MPLS with three PCN states if there are just 8 DiffServ states all in all.

What you address would then be an interdomain case of one carrier operating three states on IP whose network is connected to another carrier operating a two state network. That's an issue, but interdomain scenarios are out of scope for the time being (Phil mentioned that already).

A carrier operating with two state routers in parallel with three state routers - like running IP three state and MPLS two state - well, I'm not sure whether that makes any sense, I'd have to think about that. But to be honest, it looks as if it makes the solution more complex and that's exactly what I try to avoid, unless I can see a clear benefit for the more complex solution. What does a carrier gain if some of his routers work with three PCN states while others work with two states? 

Please also consider RFC5129 with regards to MPLS behaviour. I wonder whether IETF will accept different remarking schemes during the ultimate label popping than described there any time soon.

Regards,

Rudiger

| -----Original Message-----
| From: [email-masked] [mailto:[email-masked]] On 
| Behalf Of Wei Gengyu
| Sent: Thursday, June 19, 2008 7:05 PM
| To: [email-masked]
| Cc: [email-masked]
| Subject: Re: [PCN] Fw: draft-eardley-pcn-marking-behaviour-00
| 
| Phil,
| 
| I am not in Dublin, but I like to drink red tea while 
| disscussing the technical issues with my collegues.
| The network we often concern is the network that covers an 
| area greater than an island.
| 
| Consider the case, a university with serveral campus located 
| at different cities, it is one unversity network of a 
| collection of campus networks.
| Or the network of an enterprises with serveral branches 
| located in different states is one network.
| Those are truely existed networks nowadays.
| 
| And having experiences as a network administor will be 
| helpful to decide how to configure a network and to 
| understand the problem of coding schemes.
| 
| In your email you described the problem and the node behavior clearly.
| I do think that the problems must be solved.
| 
| In my opinion,the problems are due to the semantics of 
| 2-state and 3-state coding schemes.
| So, I argue that the WG should review coding schemes.
| 
| Regards,
| 
| Gengyu
| 
| ----- Original Message -----
| From: <[email-masked]>
| To: <[email-masked]>
| Cc: <[email-masked]>
| Sent: Wednesday, June 18, 2008 8:42 PM
| Subject: RE: [PCN] Fw: draft-eardley-pcn-marking-behaviour-00
| 
| 
| I think I may be confusing things unnecessarily.
| 
| The encoding proposal from Toby & Michael et al is structured as
| follows:
| - a baseline encoding. This uses 1 (standardised) DSCP + the ECN
| codepoints in order to encode 2 states.
| - an extension encoding. This uses a second DSCP (in addition to the
| baseline's DSCP) + the ECN codepoints and encodes 3 states.
| 
| The use of the ECN codepoints is compatible between them, in the sense
| that eg ECN 11 means some form of PCN marking in all cases - it was a
| deliberate choice to do it like this (So you could say that the 2
| encoding states are a sub-set of the 3 encoding states - 
| which is one of
| your requirements)
| 
| The baseline has already been sent to the list
| http://tools.ietf.org/id/draft-moncaster-pcn-baseline-encoding-00.txt
| - toby plans to send the extension draft soon (a draft is 
| being reviewed
| amongst the authors)
| 
| I think in your example you envisage 2 separate networks both running
| PCN which then later get merged into a single PCN-domain. So you have
| one with 2 encoding states & one with 3 encoding states (or 
| indeed: both
| have 2 encoding states, but one is using them to trigger admission
| control and one termination control, relying on other 
| mechanisms for the
| other function, or one is using the marks to trigger both admission &
| termination - ie 'single marking'). As well as the pure encoding, then
| there'll be other things to think about - eg the ingress & egress
| gateways can be in different domains and so will interpret 
| the received
| marks differently. Personally I think it's reasonable to expect
| "management" to have to be done when the 2 separate nws are joined
| together to form a single PCN-domain - ie to coordinate how PCN marks
| will be interpreted. I don't know whether something clever can be done
| that doesn't require such work - maybe it would make a good topic to
| discuss over lunch, if you're in Dublin? (I think this kind of
| discussion on 'forming a single PCN domain from two separate PCN
| domains' probably falls into the inter-domain category, which 
| is out of
| scope of PCN WG in initial charter.)
| 
| Thanks
| phil
| 
| { -----Original Message-----
| { From: Wei Gengyu [mailto:[email-masked]]
| { Sent: 18 June 2008 13:09
| { To: Eardley,PL,Philip,CXR9 R
| { Cc: [email-masked]
| { Subject: Re: [PCN] Fw: draft-eardley-pcn-marking-behaviour-00
| {
| { Phil, and all,
| {
| { I strongly suggest PCN WG review the coding scheme.
| { It is not good to have two exclusive coding algorithms in one
| technical
| { document.
| {
| { It is easy to see that 3-states have more information than 2-states.
| { It is also possible to make 2-states be the subset of three states.
| { The compatibility here means 3-state capability nodes can understand
| 2-
| { state
| { coding.
| {
| { I did not suggest to use MTU discovery or similar 
| mechanisms for node
| { clarification, neither do here.
| {
| { While remembering rudiger's words, we should face the existing
| problems of
| { networks.
| { The operator ought to knwo the nodes within its own dommains.
| { But, it is rather difficult for any operators to know the nodes of
| other
| { autonomous nodes
| { if a PCN domain covers several autonomous domains.
| {
| { I believe, it will be better if the PCN coding schemes is easy to
| deploy,
| { robust to work, and tolerant of faults.
| {
| { We do not need to make sure everything properly,
| { we only need to make 2-state capable nodes work togather 
| with 3-state
| { capable nodes.
| {
| { Regards,
| {
| { Gengyu
| {
| {
| { ----- Original Message -----
| { From: <[email-masked]>
| { To: <[email-masked]>; <[email-masked]>
| { Sent: Wednesday, June 18, 2008 4:18 PM
| { Subject: RE: [PCN] Fw: draft-eardley-pcn-marking-behaviour-00
| {
| {
| { Gengyu,
| {
| { You raise interesting questions. I'm not really sure what
| compatibility
| { means in this context - it would probably need some careful thought
| and
| { simulations /expts to work out if it could be compatible to some
| extent.
| { I'm not sure a similar mechanism to MTU discovery would be 
| appropriate
| -
| { the number of encoding states in nodes in a PCN-domain really is
| { something that the operator of that domain ought to know - 
| it doesn't
| { seem to me that this is a good thing to discover dynamically.
| {
| { I think we should remember rudiger's warning when we got into
| discussing
| { configuration issues before - it isn't our job to make sure 
| everything
| { behaves properly if something is configured incorrectly
| {
| { Best wishes
| { Phil
| {
| { { -----Original Message-----
| { { From: [email-masked] [mailto:[email-masked]] On Behalf
| Of
| { Wei
| { { Gengyu
| { { Sent: 17 June 2008 18:09
| { { To: [email-masked]
| { { Subject: [PCN] Fw: draft-eardley-pcn-marking-behaviour-00
| { {
| { {
| { { ----- Original Message -----
| { { From: "Wei Gengyu" <[email-masked]>
| { { To: <[email-masked]>
| { { Sent: Tuesday, June 17, 2008 10:41 PM
| { { Subject: Re: [PCN] draft-eardley-pcn-marking-behaviour-00
| { {
| { {
| { { > Philip,
| { { >
| { { > For the first question, your I-D in Section 2.1 is clear as you
| { said.
| { { > I got it after reading your explanations. Thank you.
| { { >
| { { > But, I still think it may be better to make 3-states nodes
| { compatible
| { { with
| { { > 2-states node.
| { { > Consider the case, if a PCN domain covers more than one 
| autonomous
| { { domain
| { { > in the Internet,
| { { > the mechanism in sechtion 2.1 could not tolerate any 
| configuration
| { { faults.
| { { >
| { { > So, if the PCN domain can works in 2-states scheme when 
| there are
| { both
| { { > 2-state and 3state nodes,
| { { > loosely-consistent checking is required in a PCN domain.
| { { >
| { { > As clarification of nodes across several autonomous domains may
| not
| { be
| { { as
| { { > easy as MTU discovery,
| { { > having the marking info compatible is probably better 
| than making
| { { encoding
| { { > choice the same in all PCN links.
| { { >
| { { > Your comments?
| { { >
| { { > Regards,
| { { >
| { { > Gengyu
| { { > School of Computer Science and Technology
| { { > Beijing University of Posts and Telecommunications
| { { >
| { { > ----- Original Message -----
| { { > From: <[email-masked]>
| { { > To: <[email-masked]>
| { { > Cc: <[email-masked]>
| { { > Sent: Tuesday, June 17, 2008 6:14 PM
| { { > Subject: RE: [PCN] draft-eardley-pcn-marking-behaviour-00
| { { >
| { { >
| { { > Gengyu
| { { >
| { { > Thanks very much for your comments!
| { { >
| { { > 1) I think this is covered in Section 2.1 (Scope), which states
| "The
| { { > same choice MUST be used throughout a PCN-domain." - this refers
| to
| { the
| { { > same choice about encoding states in all the PCN links in the
| { domain.
| { { >
| { { > In your example you have a node with 2 encoding states 
| in the same
| { { > domain as nodes with 3 encoding states. Therefore the example
| breaks
| { the
| { { > "MUST" in Section 2.1, ie the domain is misconfigured (and so
| { strictly
| { { > speaking it isn't a PCN domain, so we don't need to worry about
| it).
| { { >
| { { > If you've a suggestion how to clarify this, please let me know.
| { { >
| { { > 2) if I understand you right, you're suggesting that when a link
| is
| { { > pre-congested, it sends a message (instead of marking packets).
| Yes,
| { { > this is a possible approach, but - as you say - it's 
| out of scope
| of
| { { > PCN.
| { { >
| { { > thanks
| { { > phil
| { { >
| { { > { -----Original Message-----
| { { > { From: Wei Gengyu [mailto:[email-masked]]
| { { > { Sent: 17 June 2008 10:39
| { { > { To: Eardley,PL,Philip,CXR9 R
| { { > { Cc: [email-masked]
| { { > { Subject: Re: [PCN] draft-eardley-pcn-marking-behaviour-00
| { { > {
| { { > { Hi,
| { { > {
| { { > { I have some questions to ask after reading your I-D.
| { { > {
| { { > { 1) In a PCN domain, if the two-state node is between two
| { three-states
| { { > { nodes,
| { { > { how the marking scheme will be?
| { { > {    So is it ture if there is a two-state node along the route,
| { that
| { { > will
| { { > { be
| { { > { two-state scheme.
| { { > {    This is important for a network administrator.
| { { > { 2) In section 2.2.  Classify and condition function
| { { > {    "There may be traffic that is more important than PCN that
| { shares
| { { > the
| { { > {    same capacity as PCN and is priority scheduled over PCN
| { (perhaps an
| { { > {    operator's control messages).  Such traffic MUST be metered
| as
| { { > though
| { { > {    it were PCN-traffic, but MUST NOT be PCN-marked.  Such
| packets,
| { { > {    together with PCN-packets, are called "metered packets"."
| { { > {
| { { > {    You mentioned the packet which contains an 
| operator's control
| { { > messages,
| { { > { so my question is if the marking contexts are sent in control
| { { > messages,
| { { > { or PCN-capable nodes at ingress generat control messages when
| { sending
| { { > { marks,
| { { > { what the pcn will be?
| { { > { Perhaps the second question is out of the scope of PCN,
| { { > { but there was some schemes in ATM to send RM cell instead of
| { marking
| { { > each
| { { > { cell.
| { { > {
| { { > { Regards,
| { { > {
| { { > { Gengyu
| { { > {
| { { >
| { {
| { { _______________________________________________
| { { PCN mailing list
| { { [email-masked]
| { { https://www.ietf.org/mailman/listinfo/pcn
| 
| 
| _______________________________________________
| PCN mailing list
| [email-masked]
| https://www.ietf.org/mailman/listinfo/pcn
| 
_______________________________________________
PCN mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pcn

---

From: "Wei Gengyu" <[email-masked]>
Date: Mon, 23 Jun 2008 19:23:21 +0800

Rudiger,

I see that the decription about the scope of PCN on the PCN Homepage.
"The Congestion and Pre-Congestion Notification (PCN) working group
develops mechanisms to protect the quality-of-service of established
inelastic flows within a DiffServ domain when congestion is imminent
or existing."
"The initial scope of the PCN WG is restricted by the following
assumptions:
(A) these components are deployed in a single DiffServ domain,
where all boundary and interior nodes are PCN-enabled
and trust each other for correct PCN marking, encoding,
transport and aggregation "

But, What is is a DS domain?
I do not know where the definition of a DS domain is from.
Perhaps, all connected equipements capable of DiffServ marking form a DS 
domain. Right?

Then consider a compus network that includes Ethernet, ATM, MPLS 
equipements.
The compus network is owned and operated by the university.

My questions are
1) is the campus network a single DS domain?
2) are there both three state coding and two state coding existed if 
adopting PCN?

Regards,

Gengyu

----- Original Message ----- 
From: "Geib, Ruediger" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Friday, June 20, 2008 10:37 PM
Subject: RE: [PCN] Fw: draft-eardley-pcn-marking-behaviour-00

Gengyu,

the two state issue may specifically be relevant for carriers working with 
MPLS. Inter carrier MPLS services are possible, but still I doubt that there 
are many carriers operating MPLS with three PCN states if there are just 8 
DiffServ states all in all.

What you address would then be an interdomain case of one carrier operating 
three states on IP whose network is connected to another carrier operating a 
two state network. That's an issue, but interdomain scenarios are out of 
scope for the time being (Phil mentioned that already).

A carrier operating with two state routers in parallel with three state 
routers - like running IP three state and MPLS two state - well, I'm not 
sure whether that makes any sense, I'd have to think about that. But to be 
honest, it looks as if it makes the solution more complex and that's exactly 
what I try to avoid, unless I can see a clear benefit for the more complex 
solution. What does a carrier gain if some of his routers work with three 
PCN states while others work with two states?

Please also consider RFC5129 with regards to MPLS behaviour. I wonder 
whether IETF will accept different remarking schemes during the ultimate 
label popping than described there any time soon.

Regards,

Rudiger

---

From: "Geib, Ruediger" <[email-masked]>
Date: Tue, 24 Jun 2008 13:40:06 +0200

Gengyu 

| But, What is is a DS domain?
| I do not know where the definition of a DS domain is from.
| Perhaps, all connected equipements capable of DiffServ 
| marking form a DS domain. Right?

See RFC 2475

DS domain         a DS-capable domain; a contiguous set of
                  nodes which operate with a common set of
                  service provisioning policies and PHB
                  definitions.

| Then consider a compus network that includes Ethernet, ATM, 
| MPLS equipements.
| The compus network is owned and operated by the university.
| 
| My questions are
| 1) is the campus network a single DS domain?

Yes, presumably (unless each faculty runs an own network).

| 2) are there both three state coding and two state coding 
| existed if adopting PCN?

I don't think so. What would be the benefit of that as 
compared to the cost? If operation and planning of such a network 
is just simple, such a solution may be worth thinking about. 
But I doubt that it is simple.

Regards,

Rudiger

| 
| Regards,
| 
| Gengyu
| 
| 
| ----- Original Message -----
| From: "Geib, Ruediger" <[email-masked]>
| To: <[email-masked]>
| Cc: <[email-masked]>; <[email-masked]>
| Sent: Friday, June 20, 2008 10:37 PM
| Subject: RE: [PCN] Fw: draft-eardley-pcn-marking-behaviour-00
| 
| 
| Gengyu,
| 
| the two state issue may specifically be relevant for carriers 
| working with 
| MPLS. Inter carrier MPLS services are possible, but still I 
| doubt that there 
| are many carriers operating MPLS with three PCN states if 
| there are just 8 
| DiffServ states all in all.
| 
| What you address would then be an interdomain case of one 
| carrier operating 
| three states on IP whose network is connected to another 
| carrier operating a 
| two state network. That's an issue, but interdomain scenarios 
| are out of 
| scope for the time being (Phil mentioned that already).
| 
| A carrier operating with two state routers in parallel with 
| three state 
| routers - like running IP three state and MPLS two state - 
| well, I'm not 
| sure whether that makes any sense, I'd have to think about 
| that. But to be 
| honest, it looks as if it makes the solution more complex and 
| that's exactly 
| what I try to avoid, unless I can see a clear benefit for the 
| more complex 
| solution. What does a carrier gain if some of his routers 
| work with three 
| PCN states while others work with two states?
| 
| Please also consider RFC5129 with regards to MPLS behaviour. I wonder 
| whether IETF will accept different remarking schemes during 
| the ultimate 
| label popping than described there any time soon.
| 
| Regards,
| 
| Rudiger
| 
| 
| | -----Original Message-----
| | From: [email-masked] [mailto:[email-masked]] On
| | Behalf Of Wei Gengyu
| | Sent: Thursday, June 19, 2008 7:05 PM
| | To: [email-masked]
| | Cc: [email-masked]
| | Subject: Re: [PCN] Fw: draft-eardley-pcn-marking-behaviour-00
| |
| | Phil,
| |
| | I am not in Dublin, but I like to drink red tea while
| | disscussing the technical issues with my collegues.
| | The network we often concern is the network that covers an
| | area greater than an island.
| |
| | Consider the case, a university with serveral campus located
| | at different cities, it is one unversity network of a
| | collection of campus networks.
| | Or the network of an enterprises with serveral branches
| | located in different states is one network.
| | Those are truely existed networks nowadays.
| |
| | And having experiences as a network administor will be
| | helpful to decide how to configure a network and to
| | understand the problem of coding schemes.
| |
| | In your email you described the problem and the node 
| behavior clearly.
| | I do think that the problems must be solved.
| |
| | In my opinion,the problems are due to the semantics of
| | 2-state and 3-state coding schemes.
| | So, I argue that the WG should review coding schemes.
| |
| | Regards,
| |
| | Gengyu
| |
| | ----- Original Message -----
| | From: <[email-masked]>
| | To: <[email-masked]>
| | Cc: <[email-masked]>
| | Sent: Wednesday, June 18, 2008 8:42 PM
| | Subject: RE: [PCN] Fw: draft-eardley-pcn-marking-behaviour-00
| |
| |
| | I think I may be confusing things unnecessarily.
| |
| | The encoding proposal from Toby & Michael et al is structured as
| | follows:
| | - a baseline encoding. This uses 1 (standardised) DSCP + the ECN
| | codepoints in order to encode 2 states.
| | - an extension encoding. This uses a second DSCP (in addition to the
| | baseline's DSCP) + the ECN codepoints and encodes 3 states.
| |
| | The use of the ECN codepoints is compatible between them, 
| in the sense
| | that eg ECN 11 means some form of PCN marking in all cases 
| - it was a
| | deliberate choice to do it like this (So you could say that the 2
| | encoding states are a sub-set of the 3 encoding states -
| | which is one of
| | your requirements)
| |
| | The baseline has already been sent to the list
| | 
| http://tools.ietf.org/id/draft-moncaster-pcn-baseline-encoding-00.txt
| | - toby plans to send the extension draft soon (a draft is
| | being reviewed
| | amongst the authors)
| |
| | I think in your example you envisage 2 separate networks 
| both running
| | PCN which then later get merged into a single PCN-domain. 
| So you have
| | one with 2 encoding states & one with 3 encoding states (or
| | indeed: both
| | have 2 encoding states, but one is using them to trigger admission
| | control and one termination control, relying on other
| | mechanisms for the
| | other function, or one is using the marks to trigger both 
| admission &
| | termination - ie 'single marking'). As well as the pure 
| encoding, then
| | there'll be other things to think about - eg the ingress & egress
| | gateways can be in different domains and so will interpret
| | the received
| | marks differently. Personally I think it's reasonable to expect
| | "management" to have to be done when the 2 separate nws are joined
| | together to form a single PCN-domain - ie to coordinate how 
| PCN marks
| | will be interpreted. I don't know whether something clever 
| can be done
| | that doesn't require such work - maybe it would make a good topic to
| | discuss over lunch, if you're in Dublin? (I think this kind of
| | discussion on 'forming a single PCN domain from two separate PCN
| | domains' probably falls into the inter-domain category, which
| | is out of
| | scope of PCN WG in initial charter.)
| |
| | Thanks
| | phil
| |
| | { -----Original Message-----
| | { From: Wei Gengyu [mailto:[email-masked]]
| | { Sent: 18 June 2008 13:09
| | { To: Eardley,PL,Philip,CXR9 R
| | { Cc: [email-masked]
| | { Subject: Re: [PCN] Fw: draft-eardley-pcn-marking-behaviour-00
| | {
| | { Phil, and all,
| | {
| | { I strongly suggest PCN WG review the coding scheme.
| | { It is not good to have two exclusive coding algorithms in one
| | technical
| | { document.
| | {
| | { It is easy to see that 3-states have more information 
| than 2-states.
| | { It is also possible to make 2-states be the subset of 
| three states.
| | { The compatibility here means 3-state capability nodes can 
| understand
| | 2-
| | { state
| | { coding.
| | {
| | { I did not suggest to use MTU discovery or similar
| | mechanisms for node
| | { clarification, neither do here.
| | {
| | { While remembering rudiger's words, we should face the existing
| | problems of
| | { networks.
| | { The operator ought to knwo the nodes within its own dommains.
| | { But, it is rather difficult for any operators to know the nodes of
| | other
| | { autonomous nodes
| | { if a PCN domain covers several autonomous domains.
| | {
| | { I believe, it will be better if the PCN coding schemes is easy to
| | deploy,
| | { robust to work, and tolerant of faults.
| | {
| | { We do not need to make sure everything properly,
| | { we only need to make 2-state capable nodes work togather
| | with 3-state
| | { capable nodes.
| | {
| | { Regards,
| | {
| | { Gengyu
| | {
| | {
| | { ----- Original Message -----
| | { From: <[email-masked]>
| | { To: <[email-masked]>; <[email-masked]>
| | { Sent: Wednesday, June 18, 2008 4:18 PM
| | { Subject: RE: [PCN] Fw: draft-eardley-pcn-marking-behaviour-00
| | {
| | {
| | { Gengyu,
| | {
| | { You raise interesting questions. I'm not really sure what
| | compatibility
| | { means in this context - it would probably need some 
| careful thought
| | and
| | { simulations /expts to work out if it could be compatible to some
| | extent.
| | { I'm not sure a similar mechanism to MTU discovery would be
| | appropriate
| | -
| | { the number of encoding states in nodes in a PCN-domain really is
| | { something that the operator of that domain ought to know -
| | it doesn't
| | { seem to me that this is a good thing to discover dynamically.
| | {
| | { I think we should remember rudiger's warning when we got into
| | discussing
| | { configuration issues before - it isn't our job to make sure
| | everything
| | { behaves properly if something is configured incorrectly
| | {
| | { Best wishes
| | { Phil
| | {
| | { { -----Original Message-----
| | { { From: [email-masked] 
| [mailto:[email-masked]] On Behalf
| | Of
| | { Wei
| | { { Gengyu
| | { { Sent: 17 June 2008 18:09
| | { { To: [email-masked]
| | { { Subject: [PCN] Fw: draft-eardley-pcn-marking-behaviour-00
| | { {
| | { {
| | { { ----- Original Message -----
| | { { From: "Wei Gengyu" <[email-masked]>
| | { { To: <[email-masked]>
| | { { Sent: Tuesday, June 17, 2008 10:41 PM
| | { { Subject: Re: [PCN] draft-eardley-pcn-marking-behaviour-00
| | { {
| | { {
| | { { > Philip,
| | { { >
| | { { > For the first question, your I-D in Section 2.1 is 
| clear as you
| | { said.
| | { { > I got it after reading your explanations. Thank you.
| | { { >
| | { { > But, I still think it may be better to make 3-states nodes
| | { compatible
| | { { with
| | { { > 2-states node.
| | { { > Consider the case, if a PCN domain covers more than one
| | autonomous
| | { { domain
| | { { > in the Internet,
| | { { > the mechanism in sechtion 2.1 could not tolerate any
| | configuration
| | { { faults.
| | { { >
| | { { > So, if the PCN domain can works in 2-states scheme when
| | there are
| | { both
| | { { > 2-state and 3state nodes,
| | { { > loosely-consistent checking is required in a PCN domain.
| | { { >
| | { { > As clarification of nodes across several autonomous 
| domains may
| | not
| | { be
| | { { as
| | { { > easy as MTU discovery,
| | { { > having the marking info compatible is probably better
| | than making
| | { { encoding
| | { { > choice the same in all PCN links.
| | { { >
| | { { > Your comments?
| | { { >
| | { { > Regards,
| | { { >
| | { { > Gengyu
| | { { > School of Computer Science and Technology
| | { { > Beijing University of Posts and Telecommunications
| | { { >
| | { { > ----- Original Message -----
| | { { > From: <[email-masked]>
| | { { > To: <[email-masked]>
| | { { > Cc: <[email-masked]>
| | { { > Sent: Tuesday, June 17, 2008 6:14 PM
| | { { > Subject: RE: [PCN] draft-eardley-pcn-marking-behaviour-00
| | { { >
| | { { >
| | { { > Gengyu
| | { { >
| | { { > Thanks very much for your comments!
| | { { >
| | { { > 1) I think this is covered in Section 2.1 (Scope), 
| which states
| | "The
| | { { > same choice MUST be used throughout a PCN-domain." - 
| this refers
| | to
| | { the
| | { { > same choice about encoding states in all the PCN links in the
| | { domain.
| | { { >
| | { { > In your example you have a node with 2 encoding states
| | in the same
| | { { > domain as nodes with 3 encoding states. Therefore the example
| | breaks
| | { the
| | { { > "MUST" in Section 2.1, ie the domain is misconfigured (and so
| | { strictly
| | { { > speaking it isn't a PCN domain, so we don't need to 
| worry about
| | it).
| | { { >
| | { { > If you've a suggestion how to clarify this, please 
| let me know.
| | { { >
| | { { > 2) if I understand you right, you're suggesting that 
| when a link
| | is
| | { { > pre-congested, it sends a message (instead of marking 
| packets).
| | Yes,
| | { { > this is a possible approach, but - as you say - it's
| | out of scope
| | of
| | { { > PCN.
| | { { >
| | { { > thanks
| | { { > phil
| | { { >
| | { { > { -----Original Message-----
| | { { > { From: Wei Gengyu [mailto:[email-masked]]
| | { { > { Sent: 17 June 2008 10:39
| | { { > { To: Eardley,PL,Philip,CXR9 R
| | { { > { Cc: [email-masked]
| | { { > { Subject: Re: [PCN] draft-eardley-pcn-marking-behaviour-00
| | { { > {
| | { { > { Hi,
| | { { > {
| | { { > { I have some questions to ask after reading your I-D.
| | { { > {
| | { { > { 1) In a PCN domain, if the two-state node is between two
| | { three-states
| | { { > { nodes,
| | { { > { how the marking scheme will be?
| | { { > {    So is it ture if there is a two-state node along 
| the route,
| | { that
| | { { > will
| | { { > { be
| | { { > { two-state scheme.
| | { { > {    This is important for a network administrator.
| | { { > { 2) In section 2.2.  Classify and condition function
| | { { > {    "There may be traffic that is more important 
| than PCN that
| | { shares
| | { { > the
| | { { > {    same capacity as PCN and is priority scheduled over PCN
| | { (perhaps an
| | { { > {    operator's control messages).  Such traffic MUST 
| be metered
| | as
| | { { > though
| | { { > {    it were PCN-traffic, but MUST NOT be PCN-marked.  Such
| | packets,
| | { { > {    together with PCN-packets, are called "metered packets"."
| | { { > {
| | { { > {    You mentioned the packet which contains an
| | operator's control
| | { { > messages,
| | { { > { so my question is if the marking contexts are sent 
| in control
| | { { > messages,
| | { { > { or PCN-capable nodes at ingress generat control 
| messages when
| | { sending
| | { { > { marks,
| | { { > { what the pcn will be?
| | { { > { Perhaps the second question is out of the scope of PCN,
| | { { > { but there was some schemes in ATM to send RM cell instead of
| | { marking
| | { { > each
| | { { > { cell.
| | { { > {
| | { { > { Regards,
| | { { > {
| | { { > { Gengyu
| | { { > {
| | { { >
| | { {
| | { { _______________________________________________
| | { { PCN mailing list
| | { { [email-masked]
| | { { https://www.ietf.org/mailman/listinfo/pcn
| |
| |
| | _______________________________________________
| | PCN mailing list
| | [email-masked]
| | https://www.ietf.org/mailman/listinfo/pcn
| |
| 
| 
_______________________________________________
PCN mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pcn

---

From: "Wei Gengyu" <[email-masked]>
Date: Wed, 25 Jun 2008 23:31:30 +0800

Ruediger,

Thank you for you reply.

If one DS domain definition is from RFC 2475, the following word should be 
noticced too in this RFC2475.
This could help us to clarify what is within a singl DS domain or within an 
inter-domains.

"2.1  Differentiated Services Domain
   A DS domain normally consists of one or more networks under the same
   administration; for example, an organization's intranet or an ISP.
   The administration of the domain is responsible for ensuring that
   adequate resources are provisioned and/or reserved to support the
   SLAs offered by the domain. "

And there is no decription about constrains to DSCP when IP over ethernet, 
ATM or MPLS.
Or you can have the same coding scheme in the networks by RFC2475.

While in the I-D "draft-chan-pcn-encoding-comparison-03",
considerations of encoding are listed, but "Section 4. Encoding 
Recommendations" is blank.

Each encoding scheme is not clearly specific to a certain network technology 
underneath IP.
The sematics of DSCP are just as the network layer issues, is it right?

Regards,

Gengyu

----- Original Message ----- 
From: "Geib, Ruediger" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, June 24, 2008 7:40 PM
Subject: RE: [PCN] Fw: draft-eardley-pcn-marking-behaviour-00

Gengyu

See RFC 2475

Regards,

Rudiger

|
| Regards,
|
| Gengyu
|
|

---

From: "Geib, Ruediger" <[email-masked]>
Date: Thu, 26 Jun 2008 09:32:12 +0200

Gengyu,

RFCs dealing with IP usually just handle IP and those dealing with MPLS focus on MPLS and Ethernet standardisation is an IEEE matter. A single administration facing competition will however try to minimise her costs and this usually demands coherent deployment of services.

With regard ti marking, please keep in mind that packets transported by MPLS label switched paths may face "Pen ultimate hop popping" and be received by the destination Label Edge Router as an IP packet (given the data and control plane for the packet is IP). This packet is marked however following the marking scheme of an MPLS node. Of course you could demand, that the router differs marked packets received on a native IP interface from those received on an MPLS interface. There's no restriction however to operate interfaces in MPLS or IP only, meaning you can simultaneously receive IP packets with and without prior MPLS transport on that Label Edge Router interface. Please note, that I'm just describing trouble you cause by different PCN deployment schemes.

I'm still waiting for you to describe the benefits of mixed PCN operating schemes within a single domain. There are none, if I interpret your silence on this topic correctly.

Regards,

Rudiger

| -----Original Message-----
| From: Wei Gengyu [mailto:[email-masked]] 
| Sent: Wednesday, June 25, 2008 5:32 PM
| To: Geib, Rüdiger
| Cc: [email-masked]
| Subject: Re: [PCN] Fw: draft-eardley-pcn-marking-behaviour-00
| 
| Ruediger,
| 
| Thank you for you reply.
| 
| If one DS domain definition is from RFC 2475, the following 
| word should be noticced too in this RFC2475.
| This could help us to clarify what is within a singl DS 
| domain or within an inter-domains.
| 
| "2.1  Differentiated Services Domain
|    A DS domain normally consists of one or more networks 
| under the same
|    administration; for example, an organization's intranet or an ISP.
|    The administration of the domain is responsible for ensuring that
|    adequate resources are provisioned and/or reserved to support the
|    SLAs offered by the domain. "
| 
| And there is no decription about constrains to DSCP when IP 
| over ethernet, ATM or MPLS.
| Or you can have the same coding scheme in the networks by RFC2475.
| 
| While in the I-D "draft-chan-pcn-encoding-comparison-03",
| considerations of encoding are listed, but "Section 4. 
| Encoding Recommendations" is blank.
| 
| Each encoding scheme is not clearly specific to a certain 
| network technology underneath IP.
| The sematics of DSCP are just as the network layer issues, is 
| it right?
| 
| Regards,
| 
| Gengyu
| 
| 
| ----- Original Message -----
| From: "Geib, Ruediger" <[email-masked]>
| To: <[email-masked]>
| Cc: <[email-masked]>
| Sent: Tuesday, June 24, 2008 7:40 PM
| Subject: RE: [PCN] Fw: draft-eardley-pcn-marking-behaviour-00
| 
| 
| Gengyu
| 
| | But, What is is a DS domain?
| | I do not know where the definition of a DS domain is from.
| | Perhaps, all connected equipements capable of DiffServ
| | marking form a DS domain. Right?
| 
| See RFC 2475
| 
| DS domain         a DS-capable domain; a contiguous set of
|                   nodes which operate with a common set of
|                   service provisioning policies and PHB
|                   definitions.
| 
| 
| | Then consider a compus network that includes Ethernet, ATM,
| | MPLS equipements.
| | The compus network is owned and operated by the university.
| |
| | My questions are
| | 1) is the campus network a single DS domain?
| 
| Yes, presumably (unless each faculty runs an own network).
| 
| | 2) are there both three state coding and two state coding
| | existed if adopting PCN?
| 
| I don't think so. What would be the benefit of that as
| compared to the cost? If operation and planning of such a network
| is just simple, such a solution may be worth thinking about.
| But I doubt that it is simple.
| 
| 
| Regards,
| 
| Rudiger
| 
| |
| | Regards,
| |
| | Gengyu
| |
| |
| | ----- Original Message -----
| | From: "Geib, Ruediger" <[email-masked]>
| | To: <[email-masked]>
| | Cc: <[email-masked]>; <[email-masked]>
| | Sent: Friday, June 20, 2008 10:37 PM
| | Subject: RE: [PCN] Fw: draft-eardley-pcn-marking-behaviour-00
| |
| |
| | Gengyu,
| |
| | the two state issue may specifically be relevant for carriers
| | working with
| | MPLS. Inter carrier MPLS services are possible, but still I
| | doubt that there
| | are many carriers operating MPLS with three PCN states if
| | there are just 8
| | DiffServ states all in all.
| |
| | What you address would then be an interdomain case of one
| | carrier operating
| | three states on IP whose network is connected to another
| | carrier operating a
| | two state network. That's an issue, but interdomain scenarios
| | are out of
| | scope for the time being (Phil mentioned that already).
| |
| | A carrier operating with two state routers in parallel with
| | three state
| | routers - like running IP three state and MPLS two state -
| | well, I'm not
| | sure whether that makes any sense, I'd have to think about
| | that. But to be
| | honest, it looks as if it makes the solution more complex and
| | that's exactly
| | what I try to avoid, unless I can see a clear benefit for the
| | more complex
| | solution. What does a carrier gain if some of his routers
| | work with three
| | PCN states while others work with two states?
| |
| | Please also consider RFC5129 with regards to MPLS 
| behaviour. I wonder
| | whether IETF will accept different remarking schemes during
| | the ultimate
| | label popping than described there any time soon.
| |
| | Regards,
| |
| | Rudiger
| |
| |
| | | -----Original Message-----
| | | From: [email-masked] [mailto:[email-masked]] On
| | | Behalf Of Wei Gengyu
| | | Sent: Thursday, June 19, 2008 7:05 PM
| | | To: [email-masked]
| | | Cc: [email-masked]
| | | Subject: Re: [PCN] Fw: draft-eardley-pcn-marking-behaviour-00
| | |
| | | Phil,
| | |
| | | I am not in Dublin, but I like to drink red tea while
| | | disscussing the technical issues with my collegues.
| | | The network we often concern is the network that covers an
| | | area greater than an island.
| | |
| | | Consider the case, a university with serveral campus located
| | | at different cities, it is one unversity network of a
| | | collection of campus networks.
| | | Or the network of an enterprises with serveral branches
| | | located in different states is one network.
| | | Those are truely existed networks nowadays.
| | |
| | | And having experiences as a network administor will be
| | | helpful to decide how to configure a network and to
| | | understand the problem of coding schemes.
| | |
| | | In your email you described the problem and the node
| | behavior clearly.
| | | I do think that the problems must be solved.
| | |
| | | In my opinion,the problems are due to the semantics of
| | | 2-state and 3-state coding schemes.
| | | So, I argue that the WG should review coding schemes.
| | |
| | | Regards,
| | |
| | | Gengyu
| | |
| | | ----- Original Message -----
| | | From: <[email-masked]>
| | | To: <[email-masked]>
| | | Cc: <[email-masked]>
| | | Sent: Wednesday, June 18, 2008 8:42 PM
| | | Subject: RE: [PCN] Fw: draft-eardley-pcn-marking-behaviour-00
| | |
| | |
| | | I think I may be confusing things unnecessarily.
| | |
| | | The encoding proposal from Toby & Michael et al is structured as
| | | follows:
| | | - a baseline encoding. This uses 1 (standardised) DSCP + the ECN
| | | codepoints in order to encode 2 states.
| | | - an extension encoding. This uses a second DSCP (in 
| addition to the
| | | baseline's DSCP) + the ECN codepoints and encodes 3 states.
| | |
| | | The use of the ECN codepoints is compatible between them,
| | in the sense
| | | that eg ECN 11 means some form of PCN marking in all cases
| | - it was a
| | | deliberate choice to do it like this (So you could say that the 2
| | | encoding states are a sub-set of the 3 encoding states -
| | | which is one of
| | | your requirements)
| | |
| | | The baseline has already been sent to the list
| | |
| | 
| http://tools.ietf.org/id/draft-moncaster-pcn-baseline-encoding-00.txt
| | | - toby plans to send the extension draft soon (a draft is
| | | being reviewed
| | | amongst the authors)
| | |
| | | I think in your example you envisage 2 separate networks
| | both running
| | | PCN which then later get merged into a single PCN-domain.
| | So you have
| | | one with 2 encoding states & one with 3 encoding states (or
| | | indeed: both
| | | have 2 encoding states, but one is using them to trigger admission
| | | control and one termination control, relying on other
| | | mechanisms for the
| | | other function, or one is using the marks to trigger both
| | admission &
| | | termination - ie 'single marking'). As well as the pure
| | encoding, then
| | | there'll be other things to think about - eg the ingress & egress
| | | gateways can be in different domains and so will interpret
| | | the received
| | | marks differently. Personally I think it's reasonable to expect
| | | "management" to have to be done when the 2 separate nws are joined
| | | together to form a single PCN-domain - ie to coordinate how
| | PCN marks
| | | will be interpreted. I don't know whether something clever
| | can be done
| | | that doesn't require such work - maybe it would make a 
| good topic to
| | | discuss over lunch, if you're in Dublin? (I think this kind of
| | | discussion on 'forming a single PCN domain from two separate PCN
| | | domains' probably falls into the inter-domain category, which
| | | is out of
| | | scope of PCN WG in initial charter.)
| | |
| | | Thanks
| | | phil
| | |
| | | { -----Original Message-----
| | | { From: Wei Gengyu [mailto:[email-masked]]
| | | { Sent: 18 June 2008 13:09
| | | { To: Eardley,PL,Philip,CXR9 R
| | | { Cc: [email-masked]
| | | { Subject: Re: [PCN] Fw: draft-eardley-pcn-marking-behaviour-00
| | | {
| | | { Phil, and all,
| | | {
| | | { I strongly suggest PCN WG review the coding scheme.
| | | { It is not good to have two exclusive coding algorithms in one
| | | technical
| | | { document.
| | | {
| | | { It is easy to see that 3-states have more information
| | than 2-states.
| | | { It is also possible to make 2-states be the subset of
| | three states.
| | | { The compatibility here means 3-state capability nodes can
| | understand
| | | 2-
| | | { state
| | | { coding.
| | | {
| | | { I did not suggest to use MTU discovery or similar
| | | mechanisms for node
| | | { clarification, neither do here.
| | | {
| | | { While remembering rudiger's words, we should face the existing
| | | problems of
| | | { networks.
| | | { The operator ought to knwo the nodes within its own dommains.
| | | { But, it is rather difficult for any operators to know 
| the nodes of
| | | other
| | | { autonomous nodes
| | | { if a PCN domain covers several autonomous domains.
| | | {
| | | { I believe, it will be better if the PCN coding schemes 
| is easy to
| | | deploy,
| | | { robust to work, and tolerant of faults.
| | | {
| | | { We do not need to make sure everything properly,
| | | { we only need to make 2-state capable nodes work togather
| | | with 3-state
| | | { capable nodes.
| | | {
| | | { Regards,
| | | {
| | | { Gengyu
| | | {
| | | {
| | | { ----- Original Message -----
| | | { From: <[email-masked]>
| | | { To: <[email-masked]>; <[email-masked]>
| | | { Sent: Wednesday, June 18, 2008 4:18 PM
| | | { Subject: RE: [PCN] Fw: draft-eardley-pcn-marking-behaviour-00
| | | {
| | | {
| | | { Gengyu,
| | | {
| | | { You raise interesting questions. I'm not really sure what
| | | compatibility
| | | { means in this context - it would probably need some
| | careful thought
| | | and
| | | { simulations /expts to work out if it could be compatible to some
| | | extent.
| | | { I'm not sure a similar mechanism to MTU discovery would be
| | | appropriate
| | | -
| | | { the number of encoding states in nodes in a PCN-domain really is
| | | { something that the operator of that domain ought to know -
| | | it doesn't
| | | { seem to me that this is a good thing to discover dynamically.
| | | {
| | | { I think we should remember rudiger's warning when we got into
| | | discussing
| | | { configuration issues before - it isn't our job to make sure
| | | everything
| | | { behaves properly if something is configured incorrectly
| | | {
| | | { Best wishes
| | | { Phil
| | | {
| | | { { -----Original Message-----
| | | { { From: [email-masked]
| | [mailto:[email-masked]] On Behalf
| | | Of
| | | { Wei
| | | { { Gengyu
| | | { { Sent: 17 June 2008 18:09
| | | { { To: [email-masked]
| | | { { Subject: [PCN] Fw: draft-eardley-pcn-marking-behaviour-00
| | | { {
| | | { {
| | | { { ----- Original Message -----
| | | { { From: "Wei Gengyu" <[email-masked]>
| | | { { To: <[email-masked]>
| | | { { Sent: Tuesday, June 17, 2008 10:41 PM
| | | { { Subject: Re: [PCN] draft-eardley-pcn-marking-behaviour-00
| | | { {
| | | { {
| | | { { > Philip,
| | | { { >
| | | { { > For the first question, your I-D in Section 2.1 is
| | clear as you
| | | { said.
| | | { { > I got it after reading your explanations. Thank you.
| | | { { >
| | | { { > But, I still think it may be better to make 3-states nodes
| | | { compatible
| | | { { with
| | | { { > 2-states node.
| | | { { > Consider the case, if a PCN domain covers more than one
| | | autonomous
| | | { { domain
| | | { { > in the Internet,
| | | { { > the mechanism in sechtion 2.1 could not tolerate any
| | | configuration
| | | { { faults.
| | | { { >
| | | { { > So, if the PCN domain can works in 2-states scheme when
| | | there are
| | | { both
| | | { { > 2-state and 3state nodes,
| | | { { > loosely-consistent checking is required in a PCN domain.
| | | { { >
| | | { { > As clarification of nodes across several autonomous
| | domains may
| | | not
| | | { be
| | | { { as
| | | { { > easy as MTU discovery,
| | | { { > having the marking info compatible is probably better
| | | than making
| | | { { encoding
| | | { { > choice the same in all PCN links.
| | | { { >
| | | { { > Your comments?
| | | { { >
| | | { { > Regards,
| | | { { >
| | | { { > Gengyu
| | | { { > School of Computer Science and Technology
| | | { { > Beijing University of Posts and Telecommunications
| | | { { >
| | | { { > ----- Original Message -----
| | | { { > From: <[email-masked]>
| | | { { > To: <[email-masked]>
| | | { { > Cc: <[email-masked]>
| | | { { > Sent: Tuesday, June 17, 2008 6:14 PM
| | | { { > Subject: RE: [PCN] draft-eardley-pcn-marking-behaviour-00
| | | { { >
| | | { { >
| | | { { > Gengyu
| | | { { >
| | | { { > Thanks very much for your comments!
| | | { { >
| | | { { > 1) I think this is covered in Section 2.1 (Scope),
| | which states
| | | "The
| | | { { > same choice MUST be used throughout a PCN-domain." -
| | this refers
| | | to
| | | { the
| | | { { > same choice about encoding states in all the PCN 
| links in the
| | | { domain.
| | | { { >
| | | { { > In your example you have a node with 2 encoding states
| | | in the same
| | | { { > domain as nodes with 3 encoding states. Therefore 
| the example
| | | breaks
| | | { the
| | | { { > "MUST" in Section 2.1, ie the domain is 
| misconfigured (and so
| | | { strictly
| | | { { > speaking it isn't a PCN domain, so we don't need to
| | worry about
| | | it).
| | | { { >
| | | { { > If you've a suggestion how to clarify this, please
| | let me know.
| | | { { >
| | | { { > 2) if I understand you right, you're suggesting that
| | when a link
| | | is
| | | { { > pre-congested, it sends a message (instead of marking
| | packets).
| | | Yes,
| | | { { > this is a possible approach, but - as you say - it's
| | | out of scope
| | | of
| | | { { > PCN.
| | | { { >
| | | { { > thanks
| | | { { > phil
| | | { { >
| | | { { > { -----Original Message-----
| | | { { > { From: Wei Gengyu [mailto:[email-masked]]
| | | { { > { Sent: 17 June 2008 10:39
| | | { { > { To: Eardley,PL,Philip,CXR9 R
| | | { { > { Cc: [email-masked]
| | | { { > { Subject: Re: [PCN] draft-eardley-pcn-marking-behaviour-00
| | | { { > {
| | | { { > { Hi,
| | | { { > {
| | | { { > { I have some questions to ask after reading your I-D.
| | | { { > {
| | | { { > { 1) In a PCN domain, if the two-state node is between two
| | | { three-states
| | | { { > { nodes,
| | | { { > { how the marking scheme will be?
| | | { { > {    So is it ture if there is a two-state node along
| | the route,
| | | { that
| | | { { > will
| | | { { > { be
| | | { { > { two-state scheme.
| | | { { > {    This is important for a network administrator.
| | | { { > { 2) In section 2.2.  Classify and condition function
| | | { { > {    "There may be traffic that is more important
| | than PCN that
| | | { shares
| | | { { > the
| | | { { > {    same capacity as PCN and is priority scheduled over PCN
| | | { (perhaps an
| | | { { > {    operator's control messages).  Such traffic MUST
| | be metered
| | | as
| | | { { > though
| | | { { > {    it were PCN-traffic, but MUST NOT be PCN-marked.  Such
| | | packets,
| | | { { > {    together with PCN-packets, are called "metered 
| packets"."
| | | { { > {
| | | { { > {    You mentioned the packet which contains an
| | | operator's control
| | | { { > messages,
| | | { { > { so my question is if the marking contexts are sent
| | in control
| | | { { > messages,
| | | { { > { or PCN-capable nodes at ingress generat control
| | messages when
| | | { sending
| | | { { > { marks,
| | | { { > { what the pcn will be?
| | | { { > { Perhaps the second question is out of the scope of PCN,
| | | { { > { but there was some schemes in ATM to send RM cell 
| instead of
| | | { marking
| | | { { > each
| | | { { > { cell.
| | | { { > {
| | | { { > { Regards,
| | | { { > {
| | | { { > { Gengyu
| | | { { > {
| | | { { >
| | | { {
| | | { { _______________________________________________
| | | { { PCN mailing list
| | | { { [email-masked]
| | | { { https://www.ietf.org/mailman/listinfo/pcn
| | |
| | |
| | | _______________________________________________
| | | PCN mailing list
| | | [email-masked]
| | | https://www.ietf.org/mailman/listinfo/pcn
| | |
| |
| |
| 
| 
_______________________________________________
PCN mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pcn

---

From: <[email-masked]>
Date: Thu, 26 Jun 2008 09:21:21 +0100

{ 
{ While in the I-D "draft-chan-pcn-encoding-comparison-03",
{ considerations of encoding are listed, but "Section 4. Encoding
{ Recommendations" is blank.
{ 

the 2 moncaster-pcn encoding drafts are really the recommendations that
arose out of the comparison draft (updating comparison draft is on the
back burner at the moment)
_______________________________________________
PCN mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pcn

---

From: "Wei Gengyu" <[email-masked]>
Date: Thu, 26 Jun 2008 18:30:29 +0800

Rudiger,

Configuring nodes as a two-state encoding or three-state encoding in a 
single DS domain
is the possible problem I will meet, that was not the suggestion.

Existing I-Ds defined the two-states and three states encoding schemes.
And the behaviour of two-state and three-state capable nodes are not 
compatible
in terms of coding semantics, many independent PCN islands would be seen.

By RFC2475, a university network should be a single DS networks.
It is possible to have the mixed PCN operating schemes within a single 
domain
in the network of a university with several campuses.

We have experienced a few incompatibility problems when configuring the 
network.
The reasons said by suppliers include equipments model limitations, software 
version constrains, RFCxxxx options, or etcs.

My opinion is that if the PCN two-state and three-state options have to be 
standardized, the node behaviors should be compatible.
This will result in easy to deploy in network administration and operation. 
Do you agree?

Frankly, I am not a native speaker of English, it takes a little time to 
write the reply.
And as a serious scholar, I need to browse the references when writing 
email.

There is no necessary "to keep silence".
Whether my opinions is right or not, I take the dicussion serious on 
technology issues.

Regards,

Gengyu

----- Original Message ----- 
From: "Geib, Ruediger" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, June 26, 2008 3:32 PM
Subject: RE: [PCN] Fw: draft-eardley-pcn-marking-behaviour-00

Gengyu,

RFCs dealing with IP usually just handle IP and those dealing with MPLS 
focus on MPLS and Ethernet standardisation is an IEEE matter. A single 
administration facing competition will however try to minimise her costs and 
this usually demands coherent deployment of services.

With regard ti marking, please keep in mind that packets transported by MPLS 
label switched paths may face "Pen ultimate hop popping" and be received by 
the destination Label Edge Router as an IP packet (given the data and 
control plane for the packet is IP). This packet is marked however following 
the marking scheme of an MPLS node. Of course you could demand, that the 
router differs marked packets received on a native IP interface from those 
received on an MPLS interface. There's no restriction however to operate 
interfaces in MPLS or IP only, meaning you can simultaneously receive IP 
packets with and without prior MPLS transport on that Label Edge Router 
interface. Please note, that I'm just describing trouble you cause by 
different PCN deployment schemes.

I'm still waiting for you to describe the benefits of mixed PCN operating 
schemes within a single domain. There are none, if I interpret your silence 
on this topic correctly.

Regards,

Rudiger

---

From: "Geib, Ruediger" <[email-masked]>
Date: Thu, 26 Jun 2008 12:47:28 +0200

Gengyu, 

| Configuring nodes as a two-state encoding or three-state 
| encoding in a single DS domain is the possible problem I will 
| meet, that was not the suggestion.

Do I get you right, you point to the problem as the standard 
seems to allow two and three state coding in a single domain? 
Then the best solution is to clarify in the standard, that 
only a single mode of operation is to be deployed within a 
single domain.

[snip]

| We have experienced a few incompatibility problems when 
| configuring the network.
| The reasons said by suppliers include equipments model 
| limitations, software version constrains, RFCxxxx options, or etcs.
| 
| My opinion is that if the PCN two-state and three-state 
| options have to be standardized, the node behaviors should be 
| compatible.
| This will result in easy to deploy in network administration 
| and operation. 
| Do you agree?

I understand. Above I've formulated how I suggest to deal with 
the issue. You can then demand from each vendor to support PCN 
with two states following standard RFCxy. Two state will receive 
its own standard, three state goes to an experimental RFC.

Above trouble is of course also known to carriers and usually 
several options to deal with exist. You specify the desired 
behaviour, then you list the standards and options to be support 
in the initial Request for Information to all vendors and, if 
reliable operation is important to your company, you validate 
smooth operation in lab-tests. There may be independant 
departments within your company or university, the you have to 
support standardised interfaces. Yes, you should try to avoid 
trouble, but you'll never be able to prevent it.

Regards,

Rudiger

| 
| ----- Original Message ----- 
| From: "Geib, Ruediger" <[email-masked]>
| To: <[email-masked]>
| Cc: <[email-masked]>
| Sent: Thursday, June 26, 2008 3:32 PM
| Subject: RE: [PCN] Fw: draft-eardley-pcn-marking-behaviour-00
| 
| 
| Gengyu,
| 
| RFCs dealing with IP usually just handle IP and those dealing 
| with MPLS 
| focus on MPLS and Ethernet standardisation is an IEEE matter. 
| A single 
| administration facing competition will however try to 
| minimise her costs and 
| this usually demands coherent deployment of services.
| 
| With regard ti marking, please keep in mind that packets 
| transported by MPLS 
| label switched paths may face "Pen ultimate hop popping" and 
| be received by 
| the destination Label Edge Router as an IP packet (given the data and 
| control plane for the packet is IP). This packet is marked 
| however following 
| the marking scheme of an MPLS node. Of course you could 
| demand, that the 
| router differs marked packets received on a native IP 
| interface from those 
| received on an MPLS interface. There's no restriction however 
| to operate 
| interfaces in MPLS or IP only, meaning you can simultaneously 
| receive IP 
| packets with and without prior MPLS transport on that Label 
| Edge Router 
| interface. Please note, that I'm just describing trouble you cause by 
| different PCN deployment schemes.
| 
| I'm still waiting for you to describe the benefits of mixed 
| PCN operating 
| schemes within a single domain. There are none, if I 
| interpret your silence 
| on this topic correctly.
| 
| Regards,
| 
| Rudiger
| 
| | -----Original Message-----
| | From: Wei Gengyu [mailto:[email-masked]]
| | Sent: Wednesday, June 25, 2008 5:32 PM
| | To: Geib, Rüdiger
| | Cc: [email-masked]
| | Subject: Re: [PCN] Fw: draft-eardley-pcn-marking-behaviour-00
| |
| | Ruediger,
| |
| | Thank you for you reply.
| |
| | If one DS domain definition is from RFC 2475, the following
| | word should be noticced too in this RFC2475.
| | This could help us to clarify what is within a singl DS
| | domain or within an inter-domains.
| |
| | "2.1  Differentiated Services Domain
| |    A DS domain normally consists of one or more networks
| | under the same
| |    administration; for example, an organization's intranet 
| or an ISP.
| |    The administration of the domain is responsible for ensuring that
| |    adequate resources are provisioned and/or reserved to support the
| |    SLAs offered by the domain. "
| |
| | And there is no decription about constrains to DSCP when IP
| | over ethernet, ATM or MPLS.
| | Or you can have the same coding scheme in the networks by RFC2475.
| |
| | While in the I-D "draft-chan-pcn-encoding-comparison-03",
| | considerations of encoding are listed, but "Section 4.
| | Encoding Recommendations" is blank.
| |
| | Each encoding scheme is not clearly specific to a certain
| | network technology underneath IP.
| | The sematics of DSCP are just as the network layer issues, is
| | it right?
| |
| | Regards,
| |
| | Gengyu
| |
| |
| | ----- Original Message -----
| | From: "Geib, Ruediger" <[email-masked]>
| | To: <[email-masked]>
| | Cc: <[email-masked]>
| | Sent: Tuesday, June 24, 2008 7:40 PM
| | Subject: RE: [PCN] Fw: draft-eardley-pcn-marking-behaviour-00
| |
| |
| | Gengyu
| |
| | | But, What is is a DS domain?
| | | I do not know where the definition of a DS domain is from.
| | | Perhaps, all connected equipements capable of DiffServ
| | | marking form a DS domain. Right?
| |
| | See RFC 2475
| |
| | DS domain         a DS-capable domain; a contiguous set of
| |                   nodes which operate with a common set of
| |                   service provisioning policies and PHB
| |                   definitions.
| |
| |
| | | Then consider a compus network that includes Ethernet, ATM,
| | | MPLS equipements.
| | | The compus network is owned and operated by the university.
| | |
| | | My questions are
| | | 1) is the campus network a single DS domain?
| |
| | Yes, presumably (unless each faculty runs an own network).
| |
| | | 2) are there both three state coding and two state coding
| | | existed if adopting PCN?
| |
| | I don't think so. What would be the benefit of that as
| | compared to the cost? If operation and planning of such a network
| | is just simple, such a solution may be worth thinking about.
| | But I doubt that it is simple.
| |
| |
| | Regards,
| |
| | Rudiger
| |
| | |
| | | Regards,
| | |
| | | Gengyu
| | |
| | |
| | | ----- Original Message -----
| | | From: "Geib, Ruediger" <[email-masked]>
| | | To: <[email-masked]>
| | | Cc: <[email-masked]>; <[email-masked]>
| | | Sent: Friday, June 20, 2008 10:37 PM
| | | Subject: RE: [PCN] Fw: draft-eardley-pcn-marking-behaviour-00
| | |
| | |
| | | Gengyu,
| | |
| | | the two state issue may specifically be relevant for carriers
| | | working with
| | | MPLS. Inter carrier MPLS services are possible, but still I
| | | doubt that there
| | | are many carriers operating MPLS with three PCN states if
| | | there are just 8
| | | DiffServ states all in all.
| | |
| | | What you address would then be an interdomain case of one
| | | carrier operating
| | | three states on IP whose network is connected to another
| | | carrier operating a
| | | two state network. That's an issue, but interdomain scenarios
| | | are out of
| | | scope for the time being (Phil mentioned that already).
| | |
| | | A carrier operating with two state routers in parallel with
| | | three state
| | | routers - like running IP three state and MPLS two state -
| | | well, I'm not
| | | sure whether that makes any sense, I'd have to think about
| | | that. But to be
| | | honest, it looks as if it makes the solution more complex and
| | | that's exactly
| | | what I try to avoid, unless I can see a clear benefit for the
| | | more complex
| | | solution. What does a carrier gain if some of his routers
| | | work with three
| | | PCN states while others work with two states?
| | |
| | | Please also consider RFC5129 with regards to MPLS
| | behaviour. I wonder
| | | whether IETF will accept different remarking schemes during
| | | the ultimate
| | | label popping than described there any time soon.
| | |
| | | Regards,
| | |
| | | Rudiger
| | |
| | |
| | | | -----Original Message-----
| | | | From: [email-masked] [mailto:[email-masked]] On
| | | | Behalf Of Wei Gengyu
| | | | Sent: Thursday, June 19, 2008 7:05 PM
| | | | To: [email-masked]
| | | | Cc: [email-masked]
| | | | Subject: Re: [PCN] Fw: draft-eardley-pcn-marking-behaviour-00
| | | |
| | | | Phil,
| | | |
| | | | I am not in Dublin, but I like to drink red tea while
| | | | disscussing the technical issues with my collegues.
| | | | The network we often concern is the network that covers an
| | | | area greater than an island.
| | | |
| | | | Consider the case, a university with serveral campus located
| | | | at different cities, it is one unversity network of a
| | | | collection of campus networks.
| | | | Or the network of an enterprises with serveral branches
| | | | located in different states is one network.
| | | | Those are truely existed networks nowadays.
| | | |
| | | | And having experiences as a network administor will be
| | | | helpful to decide how to configure a network and to
| | | | understand the problem of coding schemes.
| | | |
| | | | In your email you described the problem and the node
| | | behavior clearly.
| | | | I do think that the problems must be solved.
| | | |
| | | | In my opinion,the problems are due to the semantics of
| | | | 2-state and 3-state coding schemes.
| | | | So, I argue that the WG should review coding schemes.
| | | |
| | | | Regards,
| | | |
| | | | Gengyu
| | | |
| | | | ----- Original Message -----
| | | | From: <[email-masked]>
| | | | To: <[email-masked]>
| | | | Cc: <[email-masked]>
| | | | Sent: Wednesday, June 18, 2008 8:42 PM
| | | | Subject: RE: [PCN] Fw: draft-eardley-pcn-marking-behaviour-00
| | | |
| | | |
| | | | I think I may be confusing things unnecessarily.
| | | |
| | | | The encoding proposal from Toby & Michael et al is structured as
| | | | follows:
| | | | - a baseline encoding. This uses 1 (standardised) DSCP + the ECN
| | | | codepoints in order to encode 2 states.
| | | | - an extension encoding. This uses a second DSCP (in
| | addition to the
| | | | baseline's DSCP) + the ECN codepoints and encodes 3 states.
| | | |
| | | | The use of the ECN codepoints is compatible between them,
| | | in the sense
| | | | that eg ECN 11 means some form of PCN marking in all cases
| | | - it was a
| | | | deliberate choice to do it like this (So you could say 
| that the 2
| | | | encoding states are a sub-set of the 3 encoding states -
| | | | which is one of
| | | | your requirements)
| | | |
| | | | The baseline has already been sent to the list
| | | |
| | |
| | 
| http://tools.ietf.org/id/draft-moncaster-pcn-baseline-encoding-00.txt
| | | | - toby plans to send the extension draft soon (a draft is
| | | | being reviewed
| | | | amongst the authors)
| | | |
| | | | I think in your example you envisage 2 separate networks
| | | both running
| | | | PCN which then later get merged into a single PCN-domain.
| | | So you have
| | | | one with 2 encoding states & one with 3 encoding states (or
| | | | indeed: both
| | | | have 2 encoding states, but one is using them to 
| trigger admission
| | | | control and one termination control, relying on other
| | | | mechanisms for the
| | | | other function, or one is using the marks to trigger both
| | | admission &
| | | | termination - ie 'single marking'). As well as the pure
| | | encoding, then
| | | | there'll be other things to think about - eg the 
| ingress & egress
| | | | gateways can be in different domains and so will interpret
| | | | the received
| | | | marks differently. Personally I think it's reasonable to expect
| | | | "management" to have to be done when the 2 separate nws 
| are joined
| | | | together to form a single PCN-domain - ie to coordinate how
| | | PCN marks
| | | | will be interpreted. I don't know whether something clever
| | | can be done
| | | | that doesn't require such work - maybe it would make a
| | good topic to
| | | | discuss over lunch, if you're in Dublin? (I think this kind of
| | | | discussion on 'forming a single PCN domain from two separate PCN
| | | | domains' probably falls into the inter-domain category, which
| | | | is out of
| | | | scope of PCN WG in initial charter.)
| | | |
| | | | Thanks
| | | | phil
| | | |
| | | | { -----Original Message-----
| | | | { From: Wei Gengyu [mailto:[email-masked]]
| | | | { Sent: 18 June 2008 13:09
| | | | { To: Eardley,PL,Philip,CXR9 R
| | | | { Cc: [email-masked]
| | | | { Subject: Re: [PCN] Fw: draft-eardley-pcn-marking-behaviour-00
| | | | {
| | | | { Phil, and all,
| | | | {
| | | | { I strongly suggest PCN WG review the coding scheme.
| | | | { It is not good to have two exclusive coding algorithms in one
| | | | technical
| | | | { document.
| | | | {
| | | | { It is easy to see that 3-states have more information
| | | than 2-states.
| | | | { It is also possible to make 2-states be the subset of
| | | three states.
| | | | { The compatibility here means 3-state capability nodes can
| | | understand
| | | | 2-
| | | | { state
| | | | { coding.
| | | | {
| | | | { I did not suggest to use MTU discovery or similar
| | | | mechanisms for node
| | | | { clarification, neither do here.
| | | | {
| | | | { While remembering rudiger's words, we should face the existing
| | | | problems of
| | | | { networks.
| | | | { The operator ought to knwo the nodes within its own dommains.
| | | | { But, it is rather difficult for any operators to know
| | the nodes of
| | | | other
| | | | { autonomous nodes
| | | | { if a PCN domain covers several autonomous domains.
| | | | {
| | | | { I believe, it will be better if the PCN coding schemes
| | is easy to
| | | | deploy,
| | | | { robust to work, and tolerant of faults.
| | | | {
| | | | { We do not need to make sure everything properly,
| | | | { we only need to make 2-state capable nodes work togather
| | | | with 3-state
| | | | { capable nodes.
| | | | {
| | | | { Regards,
| | | | {
| | | | { Gengyu
| | | | {
| | | | {
| | | | { ----- Original Message -----
| | | | { From: <[email-masked]>
| | | | { To: <[email-masked]>; <[email-masked]>
| | | | { Sent: Wednesday, June 18, 2008 4:18 PM
| | | | { Subject: RE: [PCN] Fw: draft-eardley-pcn-marking-behaviour-00
| | | | {
| | | | {
| | | | { Gengyu,
| | | | {
| | | | { You raise interesting questions. I'm not really sure what
| | | | compatibility
| | | | { means in this context - it would probably need some
| | | careful thought
| | | | and
| | | | { simulations /expts to work out if it could be 
| compatible to some
| | | | extent.
| | | | { I'm not sure a similar mechanism to MTU discovery would be
| | | | appropriate
| | | | -
| | | | { the number of encoding states in nodes in a 
| PCN-domain really is
| | | | { something that the operator of that domain ought to know -
| | | | it doesn't
| | | | { seem to me that this is a good thing to discover dynamically.
| | | | {
| | | | { I think we should remember rudiger's warning when we got into
| | | | discussing
| | | | { configuration issues before - it isn't our job to make sure
| | | | everything
| | | | { behaves properly if something is configured incorrectly
| | | | {
| | | | { Best wishes
| | | | { Phil
| | | | {
| | | | { { -----Original Message-----
| | | | { { From: [email-masked]
| | | [mailto:[email-masked]] On Behalf
| | | | Of
| | | | { Wei
| | | | { { Gengyu
| | | | { { Sent: 17 June 2008 18:09
| | | | { { To: [email-masked]
| | | | { { Subject: [PCN] Fw: draft-eardley-pcn-marking-behaviour-00
| | | | { {
| | | | { {
| | | | { { ----- Original Message -----
| | | | { { From: "Wei Gengyu" <[email-masked]>
| | | | { { To: <[email-masked]>
| | | | { { Sent: Tuesday, June 17, 2008 10:41 PM
| | | | { { Subject: Re: [PCN] draft-eardley-pcn-marking-behaviour-00
| | | | { {
| | | | { {
| | | | { { > Philip,
| | | | { { >
| | | | { { > For the first question, your I-D in Section 2.1 is
| | | clear as you
| | | | { said.
| | | | { { > I got it after reading your explanations. Thank you.
| | | | { { >
| | | | { { > But, I still think it may be better to make 3-states nodes
| | | | { compatible
| | | | { { with
| | | | { { > 2-states node.
| | | | { { > Consider the case, if a PCN domain covers more than one
| | | | autonomous
| | | | { { domain
| | | | { { > in the Internet,
| | | | { { > the mechanism in sechtion 2.1 could not tolerate any
| | | | configuration
| | | | { { faults.
| | | | { { >
| | | | { { > So, if the PCN domain can works in 2-states scheme when
| | | | there are
| | | | { both
| | | | { { > 2-state and 3state nodes,
| | | | { { > loosely-consistent checking is required in a PCN domain.
| | | | { { >
| | | | { { > As clarification of nodes across several autonomous
| | | domains may
| | | | not
| | | | { be
| | | | { { as
| | | | { { > easy as MTU discovery,
| | | | { { > having the marking info compatible is probably better
| | | | than making
| | | | { { encoding
| | | | { { > choice the same in all PCN links.
| | | | { { >
| | | | { { > Your comments?
| | | | { { >
| | | | { { > Regards,
| | | | { { >
| | | | { { > Gengyu
| | | | { { > School of Computer Science and Technology
| | | | { { > Beijing University of Posts and Telecommunications
| | | | { { >
| | | | { { > ----- Original Message -----
| | | | { { > From: <[email-masked]>
| | | | { { > To: <[email-masked]>
| | | | { { > Cc: <[email-masked]>
| | | | { { > Sent: Tuesday, June 17, 2008 6:14 PM
| | | | { { > Subject: RE: [PCN] draft-eardley-pcn-marking-behaviour-00
| | | | { { >
| | | | { { >
| | | | { { > Gengyu
| | | | { { >
| | | | { { > Thanks very much for your comments!
| | | | { { >
| | | | { { > 1) I think this is covered in Section 2.1 (Scope),
| | | which states
| | | | "The
| | | | { { > same choice MUST be used throughout a PCN-domain." -
| | | this refers
| | | | to
| | | | { the
| | | | { { > same choice about encoding states in all the PCN
| | links in the
| | | | { domain.
| | | | { { >
| | | | { { > In your example you have a node with 2 encoding states
| | | | in the same
| | | | { { > domain as nodes with 3 encoding states. Therefore
| | the example
| | | | breaks
| | | | { the
| | | | { { > "MUST" in Section 2.1, ie the domain is
| | misconfigured (and so
| | | | { strictly
| | | | { { > speaking it isn't a PCN domain, so we don't need to
| | | worry about
| | | | it).
| | | | { { >
| | | | { { > If you've a suggestion how to clarify this, please
| | | let me know.
| | | | { { >
| | | | { { > 2) if I understand you right, you're suggesting that
| | | when a link
| | | | is
| | | | { { > pre-congested, it sends a message (instead of marking
| | | packets).
| | | | Yes,
| | | | { { > this is a possible approach, but - as you say - it's
| | | | out of scope
| | | | of
| | | | { { > PCN.
| | | | { { >
| | | | { { > thanks
| | | | { { > phil
| | | | { { >
| | | | { { > { -----Original Message-----
| | | | { { > { From: Wei Gengyu [mailto:[email-masked]]
| | | | { { > { Sent: 17 June 2008 10:39
| | | | { { > { To: Eardley,PL,Philip,CXR9 R
| | | | { { > { Cc: [email-masked]
| | | | { { > { Subject: Re: [PCN] 
| draft-eardley-pcn-marking-behaviour-00
| | | | { { > {
| | | | { { > { Hi,
| | | | { { > {
| | | | { { > { I have some questions to ask after reading your I-D.
| | | | { { > {
| | | | { { > { 1) In a PCN domain, if the two-state node is between two
| | | | { three-states
| | | | { { > { nodes,
| | | | { { > { how the marking scheme will be?
| | | | { { > {    So is it ture if there is a two-state node along
| | | the route,
| | | | { that
| | | | { { > will
| | | | { { > { be
| | | | { { > { two-state scheme.
| | | | { { > {    This is important for a network administrator.
| | | | { { > { 2) In section 2.2.  Classify and condition function
| | | | { { > {    "There may be traffic that is more important
| | | than PCN that
| | | | { shares
| | | | { { > the
| | | | { { > {    same capacity as PCN and is priority 
| scheduled over PCN
| | | | { (perhaps an
| | | | { { > {    operator's control messages).  Such traffic MUST
| | | be metered
| | | | as
| | | | { { > though
| | | | { { > {    it were PCN-traffic, but MUST NOT be 
| PCN-marked.  Such
| | | | packets,
| | | | { { > {    together with PCN-packets, are called "metered
| | packets"."
| | | | { { > {
| | | | { { > {    You mentioned the packet which contains an
| | | | operator's control
| | | | { { > messages,
| | | | { { > { so my question is if the marking contexts are sent
| | | in control
| | | | { { > messages,
| | | | { { > { or PCN-capable nodes at ingress generat control
| | | messages when
| | | | { sending
| | | | { { > { marks,
| | | | { { > { what the pcn will be?
| | | | { { > { Perhaps the second question is out of the scope of PCN,
| | | | { { > { but there was some schemes in ATM to send RM cell
| | instead of
| | | | { marking
| | | | { { > each
| | | | { { > { cell.
| | | | { { > {
| | | | { { > { Regards,
| | | | { { > {
| | | | { { > { Gengyu
| | | | { { > {
| | | | { { >
| | | | { {
| | | | { { _______________________________________________
| | | | { { PCN mailing list
| | | | { { [email-masked]
| | | | { { https://www.ietf.org/mailman/listinfo/pcn
| | | |
| | | |
| | | | _______________________________________________
| | | | PCN mailing list
| | | | [email-masked]
| | | | https://www.ietf.org/mailman/listinfo/pcn
| | | |
| | |
| | |
| |
| |
| 
| 
_______________________________________________
PCN mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pcn