Subject: [PCN] Dealing with failure to receive reports

From: Tom Taylor <[email-masked]>
Date: Thu, 09 Feb 2012 22:17:07 -0500

In Brian Carpenter's GenArt review of the CL edge behaviour draft (but 
applicable to SM too), he noted the occurrence of the phrase "notify 
management" suggested that may indicate holes in the PCN state machine. 
This phrase is actually used in just two places: when the Decision Point 
times out waiting for a report from a PCN-egress-node, and when it times 
out waiting for one from a PCN-ingress-node.

For the PCN-egress-node case, the suggested action up to now has been to 
stop admitting new flows to the affected ingress-egress-aggregates. This 
says nothing about packets belonging to already-admitted flows. Now that 
we are committed to using tunneling to define our 
ingress-egress-aggregates, this means that if the egress node is truly 
unreachable, the ingress nodes will get "Destination unreachable" 
notifications and will need to find alternative routes. That probably 
involves a request to the Decision Point for the alternatives, since the 
choice of egress node for particular flows is affected by business 
considerations.

As a result of this reasoning, I decided to cut the process short and 
have the Decision Point impose new policy immediately upon timeout. 
Hence the following change in text.

OLD:

    If timer t-recvFail expires for a given PCN-egress-node, the Decision
    Point SHOULD notify management.  A Decision Point collocated with a
    PCN-ingress-node SHOULD cease to admit PCN-flows to the ingress-
    egress-aggregate associated with the given PCN-egress-node, until it
    again receives a report from that node.  A centralized Decision Point
    MAY cease to admit PCN-flows to all ingress-egress-aggregates
    destined to the PCN-egress-node concerned, until it again receives a
    report from that node.

NEW:

    If timer t-recvFail expires for a given PCN-egress-node, the
    Decision Point SHOULD notify management. In addition, the
    Decision Point SHOULD modify policy on the PCN-ingress-nodes
    under its control so that arriving packets that would be
    classified into the affected ingress-egress-aggregates
    are classified into alternate ingress-egress-aggregates.
    The Decision Point SHOULD restore normal classification as
    soon as it receives a report from the delinquent PCN-egress-node.

       This action probably requires pre-planning and pre-configuration
       of acceptable alternate egress points in the Decision Point. If
       rerouting to an alternate egress point does occur, it carries
       the risk that the alternate ingress-egress-aggregates exceed
       their supportable rate, necessitating flow termination.

For the analogous case of an unresponsive PCN-ingress-node, I can't 
think of any action to be taken in the PCN-domain. The upstream network 
will be the one to find an alternate route.

Comments?

Tom Taylor

---

From: Michael Menth <[email-masked]>
Date: Fri, 10 Feb 2012 08:34:44 +0100

Hi Tom,

works for me.

Best wishes,

     Michael

Am 10.02.2012 04:17, schrieb Tom Taylor:
> management" suggested that may indicate holes in the PCN state 
> machine. This phrase is actually used in just two places: when the 
> Decision Point times out waiting for a report from a PCN-egress-node, 
> and when it times out waiting for one from a PCN-ingress-node.
>
> For the PCN-egress-node case, the suggested action up to now has been 
> to stop admitting new flows to the affected ingress-egress-aggregates. 
> This says nothing about packets belonging to already-admitted flows. 
> Now that we are committed to using tunneling to define our 
> involves a request to the Decision Point for the alternatives, since 
> the choice of egress node for particular flows is affected by business 
> considerations.
>
> think of any action to be taken in the PCN-domain. The upstream 
> network will be the one to find an alternate route.
>
> Comments?
>
> Tom Taylor
>
> _______________________________________________
> PCN mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pcn

-- 
Prof. Dr. habil. Michael Menth
University of Tuebingen
Faculty of Science
Department of Computer Science
Chair of Communication Networks
Sand 13, 72076 Tuebingen, Germany
phone: (+49)-7071/29-70505
fax: (+49)-7071/29-5220
mailto:[email-masked]
http://kn.inf.uni-tuebingen.de

---

From: <[email-masked]>
Date: Fri, 10 Feb 2012 09:25:24 +0000

Hi Tom,

The modification is acceptable for me too!

Best regards,
Georgios

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Michael Menth
> Sent: vrijdag 10 februari 2012 8:35
> To: [email-masked]
> Subject: Re: [PCN] Dealing with failure to receive reports
> 
> Hi Tom,
> 
> works for me.
> 
> Best wishes,
> 
>      Michael
>

---

From: <[email-masked]>
Date: Fri, 10 Feb 2012 10:43:53 +0100

Michael, Tom,

don't we run the risk to replace a not well defined "notify management"
by a not well defined "alternate ingress-egress-aggregate"?

Do we have to recommend or discuss set up of an alternate IEA tunnel
in at least one of our documents?

Regards,

Ruediger

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Michael Menth
Sent: Friday, February 10, 2012 8:35 AM
To: [email-masked]
Subject: Re: [PCN] Dealing with failure to receive reports

Hi Tom,

works for me.

Best wishes,

     Michael

---

From: Michael Menth <[email-masked]>
Date: Fri, 10 Feb 2012 11:10:23 +0100

Hi Rüdiger,

my understanding of Tom's interpretation of Brian's "hole in the state 
machine" is that it is not clear what happens to the admitted PCN 
traffic when PCN edge nodes seem not to be reachable anymore. Rerouting 
seems a valid option to me.

Maybe we should know what Brian means with the "hole in the state 
machine" in order to fix it?

Brian, can you help, please?

Best wishes,

     Michael

---

From: Toby Moncaster <[email-masked]>
Date: Fri, 10 Feb 2012 10:21:00 +0000

Could we add something like this at the beginning to make it clear:

If timer t-recvFail expires for a given PCN-egress node it is no longer clear whether that node can support the already-admitted IEAs. The precise behaviour in this case is a matter of policy but this document recommends the following: 

Toby

On 10 Feb 2012, at 10:10, Michael Menth wrote:

> Hi Rüdiger,
> 
> my understanding of Tom's interpretation of Brian's "hole in the state machine" is that it is not clear what happens to the admitted PCN traffic when PCN edge nodes seem not to be reachable anymore. Rerouting seems a valid option to me.
> 
> Maybe we should know what Brian means with the "hole in the state machine" in order to fix it?
>

---

From: Tom Taylor <[email-masked]>
Date: Fri, 10 Feb 2012 11:43:34 -0500

I suppose I assumed all ingress nodes were already connected to all 
egress nodes, but you're right, that is not necessarily so. The whole 
thing is messy, because it is quite possible unreachability is already 
detected before the Decision Point times out and action has already been 
required. Of course, "SHOULD" covers the possibility that a switch to 
alternate egress point has already occurred. But that doesn't address 
your basic point.

I'll add discussion of setting up alternate tunnels in the Ops and 
Management section.

---

From: Tom Taylor <[email-masked]>
Date: Fri, 10 Feb 2012 11:45:06 -0500

I like this.

On 10/02/2012 5:21 AM, Toby Moncaster wrote:
> If timer t-recvFail expires for a given PCN-egress node it is no
> longer clear whether that node can support the already-admitted IEAs.
> The precise behaviour in this case is a matter of policy but this
> document recommends the following:
>
>
> Toby
>
>> my understanding of Tom's interpretation of Brian's "hole in the
>> state machine" is that it is not clear what happens to the admitted
>> PCN traffic when PCN edge nodes seem not to be reachable anymore.
>> Rerouting seems a valid option to me.
>>
>>> don't we run the risk to replace a not well defined "notify
>>> management" by a not well defined "alternate
>>> ingress-egress-aggregate"?
>>>
>>> Do we have to recommend or discuss set up of an alternate IEA
>>> tunnel in at least one of our documents?
>>>
>>> Regards,
>>>
>>> Ruediger
>>>
>>>
>>> -----Original Message----- From: [email-masked]
>>> [mailto:[email-masked]] On Behalf Of Michael Menth Sent:
>>> Friday, February 10, 2012 8:35 AM To: [email-masked] Subject: Re:
>>> [PCN] Dealing with failure to receive reports
>>>
>>> Hi Tom,
>>>
>>> works for me.
>>>
>>> Best wishes,
>>>
>>> Michael
>>>
>>>> In Brian Carpenter's GenArt review of the CL edge behaviour
>>>> draft (but applicable to SM too), he noted the occurrence of
>>>> the phrase "notify management" suggested that may indicate
>>>> holes in the PCN state machine. This phrase is actually used in
>>>> just two places: when the Decision Point times out waiting for
>>>> a report from a PCN-egress-node, and when it times out waiting
>>>> for one from a PCN-ingress-node.
>>>>
>>>> For the PCN-egress-node case, the suggested action up to now
>>>> has been to stop admitting new flows to the affected
>>>> ingress-egress-aggregates. This says nothing about packets
>>>> belonging to already-admitted flows. Now that we are committed
>>>> to using tunneling to define our ingress-egress-aggregates,
>>>> this means that if the egress node is truly unreachable, the
>>>> ingress nodes will get "Destination unreachable" notifications
>>>> and will need to find alternative routes. That probably
>>>> involves a request to the Decision Point for the alternatives,
>>>> since the choice of egress node for particular flows is
>>>> affected by business considerations.
>>>>
>>>> As a result of this reasoning, I decided to cut the process
>>>> short and have the Decision Point impose new policy immediately
>>>> upon timeout. Hence the following change in text.
>>>>
>>>> OLD:
>>>>
>>>> Decision Point SHOULD notify management.  A Decision Point
>>>> collocated with a PCN-ingress-node SHOULD cease to admit
>>>> PCN-flows to the ingress- egress-aggregate associated with the
>>>> given PCN-egress-node, until it again receives a report from
>>>> that node.  A centralized Decision Point MAY cease to admit
>>>> PCN-flows to all ingress-egress-aggregates destined to the
>>>> PCN-egress-node concerned, until it again receives a report
>>>> from that node.
>>>>
>>>> NEW:
>>>>
>>>> classified into the affected ingress-egress-aggregates are
>>>> classified into alternate ingress-egress-aggregates. The
>>>> Decision Point SHOULD restore normal classification as soon as
>>>> it receives a report from the delinquent PCN-egress-node.
>>>>
>>>> This action probably requires pre-planning and
>>>> pre-configuration of acceptable alternate egress points in the
>>>> Decision Point. If rerouting to an alternate egress point does
>>>> occur, it carries the risk that the alternate
>>>> ingress-egress-aggregates exceed their supportable rate,
>>>> necessitating flow termination.
>>>>
>>>> For the analogous case of an unresponsive PCN-ingress-node, I
>>>> can't think of any action to be taken in the PCN-domain. The
>>>> upstream network will be the one to find an alternate route.
>>>>
>>>> Comments?
>>>>
>>>> Tom Taylor
>>>>
>>>> _______________________________________________ PCN mailing
>>>> list [email-masked] https://www.ietf.org/mailman/listinfo/pcn
>>> -- Prof. Dr. habil. Michael Menth University of Tuebingen Faculty
>>> of Science Department of Computer Science Chair of Communication
>>> Networks Sand 13, 72076 Tuebingen, Germany phone:
>>> (+49)-7071/29-70505 fax: (+49)-7071/29-5220
>>> mailto:[email-masked] http://kn.inf.uni-tuebingen.de
>>>
>>> _______________________________________________ PCN mailing list
>>> [email-masked] https://www.ietf.org/mailman/listinfo/pcn
>>
>> -- Prof. Dr. habil. Michael Menth University of Tuebingen Faculty
>> of Science Department of Computer Science Chair of Communication
>> Networks Sand 13, 72076 Tuebingen, Germany phone:
>> (+49)-7071/29-70505 fax: (+49)-7071/29-5220
>> mailto:[email-masked] http://kn.inf.uni-tuebingen.de
>>
>> _______________________________________________ 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: Tom Taylor <[email-masked]>
Date: Fri, 10 Feb 2012 11:48:38 -0500

Brian can speak up on this, but it occurred to me after I sent my 
message that what he meant perhaps was what happened to flows that were 
not admitted. That's pretty basic, and I expect the architecture 
document discusses it, but I have to check.

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 11 Feb 2012 07:59:03 +1300

Tom,

That is part of it; the other part is what the thread that has
'notified management' does next - I suppose it discards state
and terminates?

In any case, saying that it's locally defined rather than standardised
would be fine for me. When I make this sort of comment, I'm trying
to stand in the shoes of someone writing code who has nothing but
the RFC to go by. Saying that it's local policy is fine, because
then the implementer gets to decide.

Regards
   Brian Carpenter