[mpls] Re: Gen-ART review of draft-ietf-mpls-p2mp-sig-requirement-03
Harald Tveit Alvestrand <harald@alvestrand.no> Thu, 24 November 2005 20:05 UTC
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfNLS-0002qo-8t; Thu, 24 Nov 2005 15:05:26 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfJXS-00031K-PG; Thu, 24 Nov 2005 11:01:35 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20174; Thu, 24 Nov 2005 11:00:53 -0500 (EST)
Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EfJqX-0004HZ-KU; Thu, 24 Nov 2005 11:21:18 -0500
Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 032A82596FB; Thu, 24 Nov 2005 17:00:53 +0100 (CET)
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30493-02; Thu, 24 Nov 2005 17:00:47 +0100 (CET)
Received: from halvestr-w2k02.emea.cisco.com (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 530AA2596F6; Thu, 24 Nov 2005 17:00:42 +0100 (CET)
Date: Thu, 24 Nov 2005 16:59:44 +0100
From: Harald Tveit Alvestrand <harald@alvestrand.no>
To: Adrian Farrel <adrian@olddog.co.uk>, gen-art@ietf.org
Message-ID: <1A809237B7C83AD209F425A0@B50854F0A9192E8EC6CDA126>
In-Reply-To: <052801c5f041$7f9af790$fb849ed9@Puppy>
References: <E022EABCC612697FBF410576@B50854F0A9192E8EC6CDA126> <052801c5f041$7f9af790$fb849ed9@Puppy>
X-Mailer: Mulberry/4.0.3 (Win32)
MIME-Version: 1.0
X-Virus-Scanned: by amavisd-new at alvestrand.no
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ba0d4c5f57f7c289496fce758bbf4798
X-Mailman-Approved-At: Thu, 24 Nov 2005 15:05:25 -0500
Cc: jeanlouis.leroux@francetelecom.com, mjork@quarrytech.com, mpls@ietf.org, andy.malis@tellabs.com, Bill Fenner <fenner@research.att.com>, jpv@cisco.com, dimitri.papadimitriou@alcatel.be
Subject: [mpls] Re: Gen-ART review of draft-ietf-mpls-p2mp-sig-requirement-03
X-BeenThere: mpls@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/mpls>
List-Post: <mailto:mpls@lists.ietf.org>
List-Help: <mailto:mpls-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@lists.ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0787967194=="
Sender: mpls-bounces@lists.ietf.org
Errors-To: mpls-bounces@lists.ietf.org
--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.....
_______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls
- [mpls] Fw: Gen-ART review of draft-ietf-mpls-p2mp… Adrian Farrel
- [mpls] Re: Gen-ART review of draft-ietf-mpls-p2mp… Adrian Farrel
- [mpls] Re: Gen-ART review of draft-ietf-mpls-p2mp… Harald Tveit Alvestrand