The MPLS WG Archive

[Harald Tveit Alvestrand <harald@alvestrand.no>]

--On 23. november 2005 15:16 +0000 Adrian Farrel <adrian@olddog.co.uk> 
wrote:

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

Yes, this makes it very clear.
>
>> 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.

This talks about the parameters (what's requested). I imply that the 
requirements include an implicit requirement that the ability to deliver on 
that promise should be reasonably consistent across the tree too - but that 
may not be necessary to say.

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

That would make me more comfortable indeed.
>
>> 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.

That reads much better to me.

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

That's exactly what I was looking for, yes!
(in bullet 3, does "messages" mean "signalling messages"? I don't think 
you've traditionally done security of data plane in RSVP-TE....)

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

It is - your fourth bullet covers this.

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

Hope it did.....

PGP signature

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