Subject: [PCN] Question on display of valid/invalid states in baseline

From: <[email-masked]>
Date: Fri, 3 Apr 2009 15:13:09 +0100

Hi All,
 
I'm just going through the very thorough comments sent in by Gorry Fairhurst about the baseline encoding draft. One of his 
comments is that the following table is unclear:
 
   +-----------+-------------+-----------------+-----------------------+
   | PCN node  |  Codepoint  | Valid codepoint | Invalid codepoint out |
   |   type    |      in     |        out      |                       |
   +-----------+-------------+-----------------+-----------------------+
   |  ingress  |     Any     | NM (or Not-PCN) |          PM           |
   | interior  |     NM      |     NM or PM    |     Not-PCN or EXP    |
   | interior  |     EXP +   |     EXP or PM   |        Not-PCN        |
   | interior  |   Not-PCN   |      Not-PCN    |  Any other codepoint  |
   | interior  |     PM      |        PM       |  Any other codepoint  |
   |  egress   |     Any     |        00       | Any other codepoint * |
   +-----------+-------------+-----------------+-----------------------+
    + This SHOULD cause an alarm to be raised at a higher layer. The
      packet MUST be treated as if it were NM.
    * Except where the egress node knows that other marks may be safely
      exposed outside the PCN-domain (e.g. [PCN-3-enc-state <http://tools.ietf.org/html/draft-ietf-pcn-baseline-encoding-02#ref-PCN-3-enc-state> ]).

            Table 2: Valid and Invalid Codepoint Transitions for
                        PCN-packets at PCN-nodes

Would people find the following table to be clearer? You read down the row
for the codepoint in and across the column for the codepoint out. At the
intersection you can find if that is a valid combination for each type of
node...
 
(In = Ingress, Mid = Interior, Out = Egress, None means that no node is 
allowed to do that transition):
 
               +----------------------------------------------------+
               |                    Codepoint Out                   |
+--------------+-------------+------------+------------+------------+
| Codepoint in | Not PCN(00) |   NM(10)   |  EXP(01)   |   PM(11)   |
+--------------+-------------+------------+------------+------------+
|  Not PCN(00) | In Mid Out  | In --- --- | -- None -- | -- None -- |
+--------------+-------------+------------+------------+------------+
|       NM(10) | In --- Out  | In Mid --- | ---None--- | -- Mid --- |
+--------------+-------------+------------+------------+------------+
|     EXP(01)+ | In --- Out  | -- None -- | -- Mid --- | -- Mid --- |
+--------------+-------------+------------+------------+------------+
|       PM(11) | In --- Out* | -- None -- | -- None -- | -- --- Out |
+--------------+-------------+------------+------------+------------+
+ This SHOULD cause an alarm to be raised at a higher layer. The
      packet MUST be treated as if it carried the NM codepoint.
* Except where the egress node knows that other marks may be safely
      exposed outside the PCN-domain (e.g. [PCN-3-enc-state <http://tools.ietf.org/html/draft-ietf-pcn-baseline-encoding-02#ref-PCN-3-enc-state> ]).

It is hard to know how to make this clearer unless one has a separate table for each of the 3 types of nodes. Basically the 
rules can be summarised as Ingress doesn't care what comes in but can only send out not-PCN or NM; Exterior nodes can 
only send out not-PCN (00); Interior nodes are more difficult: not-PCN must stay as not-PCN, PM must stay as PM, NM or EXP
can go out unchanged or can be changed to PM.
 
Toby

---

From: Tom Taylor <[email-masked]>
Date: Fri, 03 Apr 2009 10:53:59 -0400

Frankly, I'd suggest that the table only deal with the interior node case, and 
the ingress and egress transitions be described only in text as you have done. 
After all, they are pretty simple.

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

---

From: <[email-masked]>
Date: Fri, 3 Apr 2009 16:13:39 +0100

I agree - either 1 table or 3 tables. It's quite complicated with them
all in the same table, as well as raising picky points [like the '+'
alarm comment doesn't apply at the ingress]. The PM-PM box is missing a
'Mid' btw.

{ -----Original Message-----
{ From: [email-masked] [mailto:[email-masked]] On Behalf Of
Tom
{ Taylor
{ Sent: 03 April 2009 15:54
{ To: Moncaster,T,Toby,CXR9 R
{ Cc: [email-masked]
{ Subject: Re: [PCN] Question on display of valid/invalid states in
baseline
{ 
{ Frankly, I'd suggest that the table only deal with the interior node
case,
{ and
{ the ingress and egress transitions be described only in text as you
have
{ done.
{ After all, they are pretty simple.
{ 
{ [email-masked] wrote:
{ > Hi All,
{ >
{ > I'm just going through the very thorough comments sent in by Gorry
{ Fairhurst about the baseline encoding draft. One of his
{ > comments is that the following table is unclear:
{ >
{ >
+-----------+-------------+-----------------+-----------------------+
{ >    | PCN node  |  Codepoint  | Valid codepoint | Invalid codepoint
out |
{ >    |   type    |      in     |        out      |
|
{ >
+-----------+-------------+-----------------+-----------------------+
{ >    |  ingress  |     Any     | NM (or Not-PCN) |          PM
|
{ >    | interior  |     NM      |     NM or PM    |     Not-PCN or EXP
|
{ >    | interior  |     EXP +   |     EXP or PM   |        Not-PCN
|
{ >    | interior  |   Not-PCN   |      Not-PCN    |  Any other
codepoint  |
{ >    | interior  |     PM      |        PM       |  Any other
codepoint  |
{ >    |  egress   |     Any     |        00       | Any other codepoint
* |
{ >
+-----------+-------------+-----------------+-----------------------+
{ >     + This SHOULD cause an alarm to be raised at a higher layer. The
{ >       packet MUST be treated as if it were NM.
{ >     * Except where the egress node knows that other marks may be
safely
{ >       exposed outside the PCN-domain (e.g. [PCN-3-enc-state
{
<http://tools.ietf.org/html/draft-ietf-pcn-baseline-encoding-02#ref-PCN-
3-
{ enc-state> ]).
{ >
{ >             Table 2: Valid and Invalid Codepoint Transitions for
{ >                         PCN-packets at PCN-nodes
{ >
{ > Would people find the following table to be clearer? You read down
the
{ row
{ > for the codepoint in and across the column for the codepoint out. At
the
{ > intersection you can find if that is a valid combination for each
type
{ of
{ > node...
{ >
{ > (In = Ingress, Mid = Interior, Out = Egress, None means that no node
is
{ > allowed to do that transition):
{ >
{ >
+----------------------------------------------------+
{ >                |                    Codepoint Out
|
{ >
+--------------+-------------+------------+------------+------------+
{ > | Codepoint in | Not PCN(00) |   NM(10)   |  EXP(01)   |   PM(11)
|
{ >
+--------------+-------------+------------+------------+------------+
{ > |  Not PCN(00) | In Mid Out  | In --- --- | -- None -- | -- None --
|
{ >
+--------------+-------------+------------+------------+------------+
{ > |       NM(10) | In --- Out  | In Mid --- | ---None--- | -- Mid ---
|
{ >
+--------------+-------------+------------+------------+------------+
{ > |     EXP(01)+ | In --- Out  | -- None -- | -- Mid --- | -- Mid ---
|
{ >
+--------------+-------------+------------+------------+------------+
{ > |       PM(11) | In --- Out* | -- None -- | -- None -- | -- --- Out
|
{ >
+--------------+-------------+------------+------------+------------+
{ > + This SHOULD cause an alarm to be raised at a higher layer. The
{ >       packet MUST be treated as if it carried the NM codepoint.
{ > * Except where the egress node knows that other marks may be safely
{ >       exposed outside the PCN-domain (e.g. [PCN-3-enc-state
{
<http://tools.ietf.org/html/draft-ietf-pcn-baseline-encoding-02#ref-PCN-
3-
{ enc-state> ]).
{ >
{ > It is hard to know how to make this clearer unless one has a
separate
{ table for each of the 3 types of nodes. Basically the
{ > rules can be summarised as Ingress doesn't care what comes in but
can
{ only send out not-PCN or NM; Exterior nodes can
{ > only send out not-PCN (00); Interior nodes are more difficult:
not-PCN
{ must stay as not-PCN, PM must stay as PM, NM or EXP
{ > can go out unchanged or can be changed to PM.
{ >
{ > Toby
{ > _______________________________________________
{ > PCN mailing list
{ > [email-masked]
{ > https://www.ietf.org/mailman/listinfo/pcn
{ >
{ >
{ _______________________________________________
{ PCN mailing list
{ [email-masked]
{ https://www.ietf.org/mailman/listinfo/pcn