Re: [mpls] Some comments on draft-yasukawa-mpls-p2mp-oam-reqs-00.txt

["Adrian Farrel" <[e-mail]>]

Hi Dimitri,

Good of you to review...

> in section 4.2 "These functions should allow an operator to stipulate
> the maximum amount of time to wait until responses are heard from all
> points along the path, as well a cut-offs for the number of paths
tested."
>
> -> not sure to understand what "all points" means in this context, also
> if you don't receive an answer what are you going to do (is not btw a
> situation which is susceptible to occur ?)

Rereading this text I don't like it.

In answer to your question, it is exactly the case you raise that we are
trying to cover. That is, it must be possible for the operator (or
automated process) to stipulate a timeout after which the failure to see a
response shall be flagged as an error.

I don't like "as well a cut-offs for the number of paths tested." I think
this should say "branches" not "paths".

> in section 4.3 " Note that path characterization should lead to the
> operator being able to deduce the full tree for a P2MP LSP. To achieve
> this, it is important that the branching points on that tree are clearly
> identified."
>
> -> does this sentence means that a mechanism should be made available to
> poll for specific branching point liveliness ?

No.
It means that knowing the set of LSRs in a tree is not sufficient.
In order to construct the tree, it is important to know the order of LSPs
traversed and it must be possible to deduce the branch points.
Our point is that a diagnostic tool should collect information that is
easy to process rather than provide information that must be
post-processed with some complexity.
Finally, we should note that in some cases it may be possible for a branch
point to have two downstream branches (different labels) that run through
the same downstream LSR (downstream LSR is not branch capable in the data
plane) and that in this case, the branch point is not possible to deduce
from the sequence of LSRs, but must be clearly flagged.

I think we should capture some of these ideas in the I-D.

> in section 4.6 "As described in [MPLS-OAM], network elements MUST
> provide alarm suppression and aggregation to prevent the generation of
> superfluous alarms within or across network layers."
>
> -> would it be possible to be a bit more specific in the P2MP context
> what does aggregation of alarms means ? (and which alarms ?) to which
> "network layers" is this sentence referring to ? in general, i find this
> section difficult to parse

I don't think we should clarify [MPLS-OAM] within this document, so many
of your questions need to be redirected to the authors of that I-D.

Yes, we should be careful with the term "alarm aggregation" because, while
[MPLS-OAM] means aggregation from layers, we can also have aggregation
from branches as set out in the paragraph after the one you quoted.

Please note that the whole I-D applies only to MPLS networks.

> in section 4.8 "As described in [MPLS-OAM], these procedures
> will detect a broad range of defects, and SHOULD be operable where
> Since MPLS P2MP LSPs span multiple routing areas, or multiple Service
> Provider domains."
>
> -> would it be possible to clarify the beginning of the sentence refers
> to failure detection, the last part about multi-area/multi-AS ?

Hmmm. The text here seems to have been passed through our patent
Manglomatic (TM) text converter. It should read...
   Recovery from a fault by a network element can be facilitated by
   MPLS OAM procedures. As described in [MPLS-OAM], these procedures
   will detect a broad range of defects, and SHOULD be operable where
   MPLS P2MP LSPs span multiple routing areas, or multiple Service
   Provider domains.

However, I don't suppose this answers your point.
In fact, section 4.8 of [MPLS-OAM] talks about a broad range of defects
and the application to multiple routing areas and multiple SP domains, so
the text is intended to read as re-written above.

> in section 4.11 "Fundamental to understanding traffic flows within a
> network that supports P2MP LSPs will be the knowledge of where the
> branch points exist within the network."
>
> -> do you assume that the tree decomposition is unique ? it seems to me
> you need to also have the branch point relationship - clarifying what
> the term "where" means would help here

OK. We can re-work this a bit.

Thanks,
Adrian


_______________________________________________
mpls mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/mpls