Re: [Pce] Preliminary feedback on draft-pouyllau-pce-enhanced-errors-02.txt

["Ramon Casellas" <[e-mail]>]

Hélia, all,

Thank you for your comments, please see inline.

> Message: 2
> Date: Fri, 23 Jul 2010 13:43:26 +0200
> From: "POUYLLAU, HELIA (HELIA)" <[e-mail]>
> Subject: Re: [Pce] Preliminary feedback on	I.-D.
> 	draft-pouyllau-pce-enhanced-errors-02.txt

>
> 1) If I understand well, one of your concerns is about the use of error
> and notification type codes rather than TLVs. On that point you argue that
> in other documents, error-type is more related to a family of errors and
> the value to a "refinement", in the draft it is related to a kind of
> processing indication.

Correct. I would have a (weak) personal preference for a method that
extends errors and notifications by means of e.g. flags or TLVs so that:
a) it could be applied to existing errors; b) it does not imply that, for
an error whose intended treatment/process could be mapped to one of your
scenarios must have a given error type (e.g. 16,17,18) and c) it still
leaves 8+8 (hierarchical) error encoding space



> The proposal intends to allow the definition of specific errors and
> notifications but in the frame of normalized processing information. So
> you proposition about the definition of objects which could be combined in
> order to define this specific process is inline with the I-D objectives. I
> see no strong argument against it. Flags of PCEP-ERROR and NOTIFICATION
> object could also be used.

Fair enough; maybe a potential issue with current approach is that if
someone extends PCEP for some function, it may not be easy to define error
conditions, and whether to map those to the error types in your I-D or to
request the allocation of new ones. I had not thought of flags as you
mention which also seems an interesting idea.


> 2) You first comment that "an error should cause the shutdown
> of the connection, is an attribute of every particular concrete error
> pair, and belongs to its description". In the I-D, we have indeed defined

I may have not expressed myself well, but just in case, I did not imply
that all errors should cause the shutdown :) but *if* a given normative
document specifies that a given error is severe enough (e.g. to force a
shutdown) this should be mentioned in the description and related
procedures, rather than because it's an error type X (to avoid, for
example, the ambiguity of other errors that also would require a
connection shutdown which are not of type X). As mentioned, this is
personal preference too. Do we really need a way (whatever encoding) to
indicate "this error is bad enough that it forces the connection to be
shutdown" (by any of the peers)? maybe not.



> some kind of "warning". Well, this is because when you read RFC5440 the
> fact that an error causes the shutdown of the connection is not always
> mentioned. But, as you say further, the error-type which cause the

In line with the above, I always interpreted that the shutdown is only
"mandatory" (for some definition of mandatory) if the the RFC specifies
it.


> as illustrations). But you are right about your comment on section 5: it
> is not clear whether a "warning" should be defined as an error or a
> notification specific to a request. Hence, we have kept both options in
> the I-D but it is certainly true that maybe only one option should
> suffice.

This comment was raised thinking of a possible implementation. A given PCC
may have a per-PCE-peer backlog where requests are stored when sent, e.g.
in a hashed map requestid->request, with a timer to re-send the request or
to send it to another PCE, etc. Upon reception of a response
(path/nopath), or an error, the "request" is considered answered, the
timer stopped and the request is removed from the backlog. This is a well
defined criterion that seems to hold until now for most wg docs, afaik. If
we allow that, from now on, the reception on an error no longer implies
this and that a "response" (positive/negative) may come later, this is no
longer true. Maybe not a big concern, but still one :) I would (also again
personal preference) rather suggest e.g. a new message or, if needed, only
the usage of notifications to indicate "transient", "warnings" or "in the
meantime" messages.

>
> 3) Actually the use of the DLO is related to notification-type 5 of the
> I-D (propagation of the notification) and its purpose to avoid flooding.
> In section 4.3.2 it is explained that it must be used with this type. The
> use with other types is optional and maybe some "SHOULD NOT" could be
> added for some types. About you last remark on how PCC could be
> identified, it could be indeed achieved by pre-configuration. The purpose
> of the "not to PCC" option is to avoid flooding the routers of a routing
> domain - which would appear in the DLO -, which have the PCC feature but
> not the PCE.

This is clearer now, indeed. Although I still need to think about it a bit
more, in order to identify particular scenarios. In my humble view, most
use cases seem to reduce to either I) this is an error whose scope is
'this specific PCEP adjacency' defined by the PCE originating the error
and the peer or II) this is an error that should be forwarded "up the
chain" towards the original requester (even without knowing which they
are). Possibly, other use cases could be identified, but it seems to me
like a mechanism to (multi)cast a given PCE message to a set of targets,
probably related to a RP object that may not be known to all destinations.
It's like using a "mesh" of adjacencies to announce something. Any example
of use cases would be appreciated, and how they complement e.g. using the
IGP.

Thank you for your clarifications and consideration

Best regards,

Ramon