[mpls] Re: [Gen-art] Marked-up copy of draft-ietf-mpls-p2mp-sig-requirement-03 (fwd)

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

Hi Harald,

Thanks for your detailed review. Seisho and I have been through the
comments in fine detail (with Seisho doing the work as editor, and me
supplying English language text suggestions).

Most of your suggestions are fine and we have been able to make edits
which we'll publish as soon as we can close down the remaining points.

Details in line. Snipped to just the points of contention.

> Note that huge chunks of this document use the term "tree" liberally
> - but in section 4.11 you talk about "tree remerge" - which makes
> the tree be not a tree. This is confusing; if you assume a tree-shaped
> pattern, with no merges, you should say so up front; if not, you should
> avoid the term "tree".

We don't see a problem.
The issue that confused you is exactly the problem issue addressed in 4.11
(and which has taken a huge amount of effort in the solutions work). A
tree re-merge is a bad thing, but it can happen and must be handled.

> These points are equally applicable to point-to-multipoint traffic
> engineering. Points 1. and 7. are particularly important. Note that
> point 3. implies that the concept of a point-to-multipoint traffic
> trunk is defined and is supported (or mapped onto) P2MP LSPs.
>
> HTA: Supported or mapped onto? I think it wiser to stick to
> "mapped onto" only.

Well, "mapped onto" is probably not the clearest phrase and doesn't
actually have any meaning! "Supported by" has some meaning and we would
prefer to use just that phrase, but since 2702 uses "mapped onto" it is
provided here for completeness.

> Existing MPLS TE mechanisms such as [RFC3209] do not support P2MP TE
> LSPs so new mechanisms need to be developed. This should be achieved
> with maximum re-use of existing MPLS protocols.
>
> Note that there is a separation between routing and signaling in
> MPLS TE. In particular, the path of the MPLS TE LSP is determined by
> performing a constraint-based computation (such as CSPF) on a traffic
> engineering database (TED). The contents of the TED may be collected
> through a variety of mechanisms.
>
> This document focuses on requirements for establishing and
> maintaining P2MP MPLS TE LSPs through signaling protocols; and
> routing protocols are out of scope. No assumptions are made about
> how the TED used as the basis for path computations for P2MP LSPs is
> formed.
>
> HTA: These three paragraphs add no information - neither make
> requirements nor make the problem easier to understand. Suggest
> removing.

We have given the first paragraph a "SHOULD" to make it conform.
The second and third paragraphs are the result of long and painful
discussion across several working groups. If they do no harm, then they
should stay as removing them would probably upset someone.

> o Tunnel endpoints of P2MP TE LSP will be modified by adding/removing
>    egress LSRs to/from an existing P2MP TE LSP. It is assumed that the
> HTA: English - "Tunnel endpoints" is different from "receivers" how?

A receiver is an IP multicast or unicast receiver.
A tunnel end point is the end of a tunnel.
Note that it is usual for a TE tunnel to not extend all the way to the
receiver.
Text was not clear and we have made changes.

>   rate of change of leaves of a P2MP service (that is, the rate at
>   which new egress LSRs join, or old egress LSRs are pruned) is "not
>   so high" because P2MP TE LSPs are assumed to be utilized for TE
>   applications. This issue is discussed at greater length in section
>   4.18.1.
> HTA: Since "TE applications" is undefined, this adds no information.
> I'd stick a number in here (10 join/leaves per day) and leave it at
> that.

If you'd like to come to the MPLS working group and argue that 10
join/leaves per day is reasonable, then you have better asbestos than we
do!  :-)

The referenced section is quite careful about this, and we think that "TE
application" is well enough understood in the context of 4207.

> 1.1 Non-Objectives
[snip]
>
> The following are non-objectives of this document.
> HTA: I don't understand this section. A "non-objective" may be
> understood in multiple ways:
[snip]
> I think it would be simpler if this section said "This document does
> not specify any requirements for the following functions".

Agreed.

> In that case, the "algorithms" point does not fit, and should be
> dropped.

Huh? This document certainly does not specify any requirements for
algorithms.
Given that there was a lot of discussion in the WG about whether
algorithms were in or out of scope, we wished to explicitly state that
they are out of scope.

> 3.2. Requirements Overview
>
> The P2MP TE LSP setup mechanism MUST include the ability to
> add/remove egress LSRs to/from an existing P2MP TE LSP and MUST
> allow for the support of all the TE LSP management procedures
> HTA: Would like to say "all the applicable TE LSP.." - see comment about
> the establishment of bidirectional tunnels earlier.

Not convinced by your point.
First, "all applicable" is no help to the reader.
Secondly, we are talking here about LSP management procedures. All of the
management procedures in 2702 seem to be applicable.

> The following are the objectives of P2MP LSP establishment and use.
>
>  d) If a new receiver (R5) expresses an interest in receiving
>     traffic, a new tree is determined and a B2L sub-LSP from
>     LSR2 to E-LSR5 is grafted onto the P2MP TE LSP. LSR2 becomes a
>     branch LSR.
>
> HTA: It's unclear to me whether the requirements want to say anything
> about who does this - is it envisioned that R5 expresses the interest to
> either S1 or I-LSR1, and that I-LSR1 initiates the change, or is it
> envisioned that R5 can express interest straigtht to LSR2 or E-LSR5,
> without involving S1 or I-LSR1 in the process?

Both, either, or neither. R5 could express its interest to a third party
(e.g. NMS).

This is very out of scope. See the second non-objective in section 1.1.

> 4.5 Fragmentation
>
> HTA: This section is extremely strange, in that it seems to warn
> against a particular choice in a particular solution - not stating the
> requirement at all. I'd suggest just saying
>
> The solution MUST allow the establishing of large P2MP LSPs
> (with a large number of LSRs and recipients being identified).
> Note that the set of identified LSRs can grow at transit nodes.
>
> and leave the packet sizes out of it entirely.

It is hard to review this section without the history and politics. Of
course, what is going on here is specific to particular solutions, but to
leave it out will cause a war because it will appear to allow a "bad"
solution to be implemented.

Although this section contains far too many words, we don't want to
suggest removal of any of them.

> 4.11 Tree Remerge
>
> The solution MUST support the case where of multiple signaling
> messages for the same P2MP LSP are received at a single transit LSR
> and refer to the same upstream interface. In this case the result of
> the protocol procedures SHOULD be a single data flow on the upstream
> interface.
>
> HTA: The more interesting question is whether there's a single data
> flow on the downstream interfaces - I think the answer is "yes".

Hmmm.
The answer is actually no.
If there is more than one downstream interface, there had better be more
than one data flow.

The case you are concerned about (multiple signaling related to the same
downstream interface) is described later in the same section.

Cheers,
Adrian and Seisho

PS Word version with change markers available on request.


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