[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PCN] Dealing with failure to receive reports
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?
>
> Brian, can you help, please?
>
> Best wishes,
>
> Michael
>
> Am 10.02.2012 10:43, schrieb Ruediger.Geib at telekom.de:
>> 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: pcn-bounces at ietf.org [mailto:pcn-bounces at ietf.org] On Behalf Of Michael Menth
>> Sent: Friday, February 10, 2012 8:35 AM
>> To: pcn at ietf.org
>> Subject: Re: [PCN] Dealing with failure to receive reports
>>
>> Hi Tom,
>>
>> works for me.
>>
>> Best wishes,
>>
>> Michael
>>
>> Am 10.02.2012 04:17, schrieb Tom Taylor:
>>> 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
>>>
>>> _______________________________________________
>>> PCN mailing list
>>> PCN at ietf.org
>>> 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:menth at uni-tuebingen.de
>> http://kn.inf.uni-tuebingen.de
>>
>> _______________________________________________
>> PCN mailing list
>> PCN at ietf.org
>> 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:menth at uni-tuebingen.de
> http://kn.inf.uni-tuebingen.de
>
> _______________________________________________
> PCN mailing list
> PCN at ietf.org
> https://www.ietf.org/mailman/listinfo/pcn