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

[dimitri papadimitriou <[e-mail]>]

hi adrian,

Adrian Farrel wrote:

> 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.

ok - much clearer

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

shouldn't you also include a cut-off in terms of number of egresses then

>>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.

ok - i understand the meaning behind the sentence - i would suggest to 
refine the notion of "path characterization" in this sentence (see 
section 4.3 of the P2P document) but more importantly to add "sequence 
of branching points" or equivalent

> 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.

imho, this is a specific requirement that should normally be pointed as 
part of the text

> 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.

indeed, i would also suggest having an extended version of this for 
deducing more generic cross-over branching points

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

ok -

>>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.

i understand your redirect and will do because the statement in the 
referenced doc is not indicated as being aggregation *from layers*

> 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.

ok -

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

noted

>>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.

ok - but how do you link this with the path characterization where there 
is a need to "being able to deduce the full tree for a P2MP LSP" are you 
sure across AS, or providers the full tree topology will be made possible ?

>>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.

ok - if you need some text/help let me know


> Thanks,
> Adrian
> 
> 
> .
> 

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