[mpls] Re: Gen-ART review of draft-ietf-mpls-p2mp-sig-requirement-03

Hi Harald,

Thanks for your comments on this I-D.

> (Impressively long authors' section!)
>
> This is not an unreasonable document. However, I cannot recommend
> that it be published as-is.
>
> The chief reason is that it does not properly define its target mission.
> For a document that is a requirements document for point-to-
> multipoint signalling, it strangely never defines what a point-to-
> multipoint service is.
>
> From context, it appears to be an unidirectional service capable of
> delivering a signal (a lightstream, bitstream or packet stream?) to
> multiple destinations.

Would the following text help?

   A point-to-multipoint (P2MP) TE LSP is a TE LSP in the definitions of
[RFC2702]
   and [RFC3031] that has a single ingress, one or more egresses, and is
unidirecitonal.
   P2MP services (that deliver data from a single source to one or more
receivers) may
   be supported by any combination of P2P and P2MP LSPs depending on the
degree
   of optimization required within the network, and such LSPs may be
Traffic
   Engineered again depending on the requirements of the network. Further,
MP2MP
   services (that deliver data from more than one source to one or more
receivers) may
   be supported by a combination of P2P and P2MP LSPs.

> But it never discusses the metric that distinguish
> such a service from a P2P service - namely, whether or not there is a
> requirement for a consistent service to all destinations, or whether the
> consistency is part of the quality constraints that the solution has to
> allow explicit engineering for.

I am not convinced that this is the distinction between a P2P service and
a P2MP service. I think that the only distinction is that a P2MP service
may have more than one receiver.

Note that an LSP is *not* a service. It is a building block that may be
used to provide a service. I see no reason why one shouldn't have a
service that delivers multicast where some receivers have guaranteed
quality and others have best-effort quality. It is all a matter of the
definition of the service.

One might support such a service using multiple LSPs (no change here from
P2P services which may be supported by multiple LSPs).

Note also that section 4.9 (Variation of LSP Parameters) is very
particular about the consistency of the branches of a P2MP LSP, but that
does not reflect on the service.

I don't propose any changes for this issue.

> The control model of the service is also unclear.
>
> From context, it appears that one envisions that recipients can
> join and leave the tree while it's running; it's not clear whether
> the requirement is like that for a P2P path, where establishment
> always involves the head-end of the path, or whether a reasonable
> solution to the requirements can allow grafting and pruning down
> the tree without the head-end being involved (as happens in the
> "traditional IP multicast" service).

I think the comparison with a P2P path is a distraction! It is impossible
to have any path without involvement of the data source, and it becuase of
this that it is in the nature of a P2P path that the ingress and the
(single) egress are involved in the establishment of the path.

But your question is really about whether it is possible for leaves to be
added and removed without the knowledge or participation of the ingress.
As you say, the document makes no requirements in this regard, and that is
deliberate: it is left open to the solution work to select an operational
mode that is consistent with the solution technology. I think that this is
how the service model for "traditional IP multicast" came about.

We could make a statement about this non-requirement. Would that make you
more comfortable? We would say something like...
   It is not a requirement that the ingress must control the addition
   or removal of leaves from the P2MP tree.

> Section 4.20 (on GMPLS) is a surprise. While the rest of the document
> has been carefully phrased in technology-avoiding language (although
> concepts that I think of as RSVP-TE shine through on a regular basis),
> this section blatantly specifies specific RSVP-TE objects and features
> that "have to be" supported. This seems out of place.

You are correct that the reference to RSVP-TE objects are out of place.
The features, however, are not RSVP-TE-specific and should remain. I would
propose to change section 4.20 as follows:

4.20 GMPLS

   The requirement for P2MP services for non-packet switch interfaces
   is similar to that for Packet-Switch Capable (PSC) interfaces.
   Therefore, it is a requirement that reasonable attempts must be made
   to make all the features/mechanisms (and protocol extensions) that
   will be defined to provide MPLS P2MP TE LSPs equally applicable to
   P2MP PSC and non-PSC TE-LSPs. If the requirements of non-PSC networks
   over-complicate the PSC solution a decision may be taken to separate
   the solutions.

   Solutions for MPLS P2MP TE-LSPs when applied to GMPLS P2MP PSC or
   non-PSC TE-LSPs MUST be backward and forward compatible with the
   other features of GMPLS including:

   - control and data plane separation,
   - full support of numbered and unnumbered TE links,
   - use of the arbitrary labels for and labels for specific technologies,
as well as
     negotiation of labels where necessary to support limited label
processing and
     swapping capabilities,
   - the ability to apply external control to the labels selected on each
hop of the
     LSP, and to control the next hop label/port/interface for data after
it reaches
     the egress,
   - support for graceful and alarm-free enablement and termination of
LSPs,
   - full support for proteciton including link level protection,
end-to-end protection
     and segment protection,
   - the ability to teardown an LSP from a downstream LSR, in particular
from the
     egress,
   - support for failure and restart or reconnection of the control plane
without any
      disruption of the data plane.

   In addition, since non-PSC TE-LSPs may have to be processed in
   environments where the "P2MP capability" could be limited, specific
   constraints may also apply during the P2MP TE Path computation.
   Being technology specific, these constraints are outside the scope
   of this document. However, technology independent constraints
   (i.e. constraints that are applicable independently of the LSP
   class) SHOULD be allowed during P2MP TE LSP message processing.
   It has to be emphasized that path computation and management
   techniques shall be as close as possible to those being used for
   PSC P2P TE LSPs and P2MP TE LSPs.

> The document's security section is inadequate. For a requirements
> document, I expect the security section to state the security
> requirements for a solution - in this case, these are likely to be
> very similar to those for P2P signalling, which (if I understand it
> correctly) involve identifying the LSRs to each other, and validating
> that the requester of service has the right to request service (which
> requires head-end identification to all downstream nodes in some
> fashion).

I am generally a supporter of getting as much detail as possible into
security sections early in the process. However, it seems peculiar to me
that you should suggest that a requirements I-D that is wholly protocol-
and solutions-neutral should need to specify the security issues that
might arise if a particular solutions option is chosen. Clearly we
couldn't hope to describe the security issues for every possible solution.

In order to handle the (likely) case that P2MP MPLS-TE is achieved through
extensions to RSVP-TE we included a specific paragraph to raise the flag
that P2MP signaling solutions cannot assume that they are as secure as the
P2P solutions on which they are built.
   It should be noted that P2MP signaling mechanisms built on P2P
   RSVP-TE signaling are likely to inherit all of the security
   techniques and problems associated with RSVP-TE. These problems may
   be exacerbated in P2MP situations where security relationships may
   need to maintained between an ingress and multiple egresses. Such
   issues are similar to security issues for IP multicast.

But all of this is just a specific to RSVP-TE, and you are after someting
more generic. How about the following extra paragraph?

   It is a requirement that any P2MP solution developed to meet some
   or all of the requirements expressed in this document MUST include
   mechanisms to enable the secure establishment and management of
   P2MP MPLS-TE LSPs. This includes, but is not limited to:
   - mechanisms to ensure that the ingress of a P2MP LSP is identified
   - mechanisms to ensure that communicating signaling entites can
     verify each other's identities
   - mechanisms to ensure that messages are protected against spoofing
     and tampering
   - mechanisms to ensure that unauthorised leaves or branches are not
     added to the P2MP LSP
   - mechanisms to protect signaling messages from snooping.

> In the P2MP context, I would also expect requirements on the
> listeners - whether or not the head-end is required to be able to
> identify all egress points seems like a security issue to me.

Don't think I understand you, but maybe this is covered in my proposed
text?

> I'm also unhappy with the clarity of the writing in a number of places -
> I'll follow up with another message containing a marked-up copy of the
> draft.

Looking forward to that.

> Hope this is helpful.

If it has improved the quality of the document in a significant measure
then it was helpful.

Adrian

_______________________________________________
mpls mailing list
mpls@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/mpls