Re: [Pce] Benjamin Kaduk's No Objection on draft-ietf-pce-association-diversity-12: (with COMMENT)
Mahend Negi <mahend.ietf@gmail.com> Wed, 18 December 2019 16:22 UTC
Return-Path: <mahend.ietf@gmail.com>
X-Original-To: pce@ietfa.amsl.com
Delivered-To: pce@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 082E6120983; Wed, 18 Dec 2019 08:22:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qzqHJrdIAyv9; Wed, 18 Dec 2019 08:22:25 -0800 (PST)
Received: from mail-ot1-x332.google.com (mail-ot1-x332.google.com [IPv6:2607:f8b0:4864:20::332]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1517D12096B; Wed, 18 Dec 2019 08:22:22 -0800 (PST)
Received: by mail-ot1-x332.google.com with SMTP id h9so569194otj.11; Wed, 18 Dec 2019 08:22:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jgv2UUscqbetSBED75SgJweru/UHpIedfHPae3Ko1bU=; b=SDAsvredprfH4hYy8XtEAQfpO6gABuM+4lfZxNzWbg7R0MWlUqdGIU8scAn6uCr8hF al8WY+RKy1+7fk5CXAHe3C2dED7YDdBUXjC+ehON5vnOKWWR1peXAeeAzKlQp2/uggV7 O67YZcJCawEvHLiZylQw9TxKNq+M0T3IyQ/FGmS5Yi3ky8P/1IfBUTePp40RET9DMnvo 5zukUs7aDEHcSiyAFqLawpdRkrmBumhtzJJB50N2RyZQ24iI0lmeCUf9KNdR8VPlr+td Ef4/bdufI5M/bSb8Itwijb16RM51N/5xQhEYXafMe3aGJTF/LE3dWn2VSsMfqVnH3I3D HfJA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=jgv2UUscqbetSBED75SgJweru/UHpIedfHPae3Ko1bU=; b=oFVQAJu8qGrKPhJiTBnByLceRLBYIOnEzb6NlU1leIUqshW+K4XVZzddxMAA2bTXqU iZm/f4ofiOs5qPgoDakxvZOi8kXYU5Hvbu7ZbqfjmGP9bVlb24pvN3fXr+PRIx8EJ6rK 9mmtTx0P8C0OBjXo4qEZ3Dt4xD4JcH3pedlcoB+teigMzU6Nq7dNHlQrKsKu2DmZNUhK /f+axuXWkD1aRNGtvZYbdSYXJHdZYWTRPEGxm+o9A+zwUxaIZK9mzzqtciiLkV0YjLnA 403Q5tbjjVbLMP9OD4BTg8GYsATNICJ58eAVxdG3dWDROIXQ663tCccm29vb8I3UHczC aSag==
X-Gm-Message-State: APjAAAWphAbpeJzoiJiWYy+9qEhwCbMd2PHHxve4Nha5eP0KkBLKH01R y6b3HHYmgs9tYYSizJzIsIHQ8N9j4iqzI4/4KHE=
X-Google-Smtp-Source: APXvYqwLn2Hl5kt7kx6nXkHKkRozV0O/Sfzg+Rf06SCyxlQLdpG7IAIxcX3ZJb/1WAHoY6cWQz8rbVBHAiyTWXDGWa8=
X-Received: by 2002:a9d:798e:: with SMTP id h14mr3287654otm.257.1576685773711; Wed, 18 Dec 2019 08:16:13 -0800 (PST)
MIME-Version: 1.0
References: <157239405775.10912.18424489553959713397.idtracker@ietfa.amsl.com>
In-Reply-To: <157239405775.10912.18424489553959713397.idtracker@ietfa.amsl.com>
From: Mahend Negi <mahend.ietf@gmail.com>
Date: Wed, 18 Dec 2019 21:46:02 +0530
Message-ID: <CAM5Nu_w4K0=vSB8CZX639SWhs+Dgq320DhETdeB4MgMbNeJLFA@mail.gmail.com>
To: Benjamin Kaduk <kaduk@mit.edu>
Cc: The IESG <iesg@ietf.org>, draft-ietf-pce-association-diversity@ietf.org, Julien Meuric <julien.meuric@orange.com>, pce-chairs <pce-chairs@ietf.org>, pce@ietf.org
Content-Type: multipart/alternative; boundary="00000000000076ef390599fcc312"
Archived-At: <https://mailarchive.ietf.org/arch/msg/pce/jg4Cm-Fjh0O35cDoYHR4Fo8Qzf4>
Subject: Re: [Pce] Benjamin Kaduk's No Objection on draft-ietf-pce-association-diversity-12: (with COMMENT)
X-BeenThere: pce@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Path Computation Element <pce.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pce>, <mailto:pce-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pce/>
List-Post: <mailto:pce@ietf.org>
List-Help: <mailto:pce-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pce>, <mailto:pce-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 18 Dec 2019 16:22:29 -0000
Hi Ben, Thanks for the detailed review, please find the details inline to your mail. B/w new version is uploaded. htmlized versions available at: https://tools.ietf.org/html/draft-ietf-pce-association-diversity-13 https://datatracker.ietf.org/doc/html/draft-ietf-pce-association-diversity-13 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-association-diversity-13 Thanks, Mahendra On Wed, Oct 30, 2019 at 5:37 AM Benjamin Kaduk via Datatracker < noreply@ietf.org> wrote: > Benjamin Kaduk has entered the following ballot position for > draft-ietf-pce-association-diversity-12: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-pce-association-diversity/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Thanks for this generally well-written document! Most of my comments are > pretty minor, but please do note the edge case in objective function > handling, the question about which TLVs are allowed when the ASSOCIATION > object is carried in which messages, the notation clarification question, > and the question about what "completely relax the disjointness constraint" > means. > > Please check the TBD<N> placeholders; it looks like (e.g.) TBD8 is used for > both a NO-PATH-VECTOR TLV bit and for an error code (but I didn't > double-check the others). > > > On Wed, Oct 30, 2019 at 5:37 AM Benjamin Kaduk via Datatracker > <noreply@ietf.org> wrote: > > > > Benjamin Kaduk has entered the following ballot position for > > draft-ietf-pce-association-diversity-12: No Objection > > > > When responding, please keep the subject line intact and reply to all > > email addresses included in the To and CC lines. (Feel free to cut this > > introductory paragraph, however.) > > > > > > Please refer to > https://www.ietf.org/iesg/statement/discuss-criteria.html > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-pce-association-diversity/ > > > > > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > Thanks for this generally well-written document! Most of my comments are > > pretty minor, but please do note the edge case in objective function > > handling, the question about which TLVs are allowed when the ASSOCIATION > > object is carried in which messages, the notation clarification question, > > and the question about what "completely relax the disjointness > constraint" > > means. > > > > Please check the TBD<N> placeholders; it looks like (e.g.) TBD8 is used > for > > both a NO-PATH-VECTOR TLV bit and for an error code (but I didn't > > double-check the others). > > > > Fixed. > > As a general comment (but mostly for my own curiousity), I'm curious > whether > you predict much usage of the DAG association type with none of the L/N/S/T > bits set in the configuration, effectively using the association to carry > the new objective function(s) from this document. > > Yes, your interpretation is correct. > > Section 5.1 > > A disjoint group can have two or more LSPs, but a PCE may be limited > in the number of LSPs it can take into account when computing > disjointness. If a PCE receives more LSPs in the group than it can > handle in its computation algorithm, it SHOULD apply disjointness > computation to only a subset of LSPs in the group. The subset of > disjoint LSPs will be decided by PCE as a local policy. Local > > Just to double-check: this "only apply disjointness to a subset, using > local > policy" behavior is preferred to returning an error for the last LSP > attempting to join the group? I do see that the relaxation of disjointness > is reported back via the DISJOINTNESS-STATUS-TLV, so at least there > shouldn't be surprises about what's (not) happening, unless the PCE decides > to not send that TLV for some reason. > Yes, but the key here is for "computation algorithm" limitation. There > is a generic error in > https://tools.ietf.org/html/draft-ietf-pce-association-group-10#section-6.4 > that might still be applied in case of too many LSPs irrespective of the > limitation of the disjoint computation algorithm. > > > of T, S, N, L flags in the DISJOINTNESS-CONFIGURATION-TLV. If a PCEP > peer receives a PCEP messages for LSPs belonging to the same disjoint > group but having an inconsistent combination of T, S, N, L flags, the > PCEP peer MUST NOT try to add the LSPs in disjoint group and MUST > reply with a PCErr with Error-type 26 (Association Error) and Error- > Value 6 (Association information mismatch). > > nit: s/in disjoint group/to the disjoint group/ > > A particular LSP MAY be associated to multiple disjoint groups, but > in that case, the PCE SHOULD try to consider all the disjoint groups > during path computation if possible. Otherwise a local policy MAY > define the computational behavior. If a PCE does not support such a > path computation it MUST NOT add the LSP into association group and > return a PCErr with Error-type 26 (Association Error) and Error-Value > 7 (Cannot join the association group). > > It's interesting that "be in multiple disjoint groups" gets > error-on-failure > semantics but (above) "too many LSPs in a single group" gets > degrade-and-report semantics. But it's clearly documented, so I don't see > any problems per se. > > Section 5.2 > > It looks like we only talk about which messages carry the > DISJOINTNESS-STATUS-TLV; is the implication that the other TLVs are not > restricted in which message can carry them a correct one? (Also, that > DISJOINTNESS-CONFIGURATION-TLV must be present even in PCRep?) > > Yes. In PCRep both the TLVs are included. The disjoint group MUST carry the following TLV: > > Since we're talking about protocol elements now, I'd suggest to explicitly > say "TBD1 Disjoint Association Type group" or something else that clearly > identifies the association-group as a protocol element. > > ACK > In addition, the disjoint group MAY carry the following TLV: > > nit: "TLVs" plural. > > If a PCEP speaker receives a disjoint-group without DISJOINTNESS- > CONFIGURATION-TLV, it SHOULD reply with a PCErr Error-type=6 > (Mandatory Object missing) and Error-value=TBD8 (DISJOINTNESS- > CONFIGURATION-TLV missing). > > I suggest being more explicit about (e.g) "ASSOCIATION object of type > TBD1", > since "disjoint-group" is somewhat of a colloquialism. > > ACK > > Seciion 5.3 > > An objective function (OF) MAY be applied to the disjointness > computation to drive the PCE computation behavior. In this case, the > OF-List TLV (defined in ([RFC5541]) is used as an optional TLV in the > Association Group Object. Whereas the PCEP OF-List TLV allows > multiple OF-codes inside the TLV, a sender SHOULD include a single > OF-code in the OF-List TLV when included in the Association Group, > and the receiver MUST consider the first OF-code only and ignore > others if included. > > This usage seems a little weird (albeit unlikely to be problematic), since > RFC 5441 uses the OF-List TLV to indicate what OFs are supported, and has > it > carried in the OPEN object, with a dedicated OF object used to indicate the > particular OF requested/used for a given path computation. Repurposing the > TLV to now be a container for the requested OF for a specific computation > feels like a qualitatively different usage than the original one. > > Agreed, defining a new TLV that only allows one OF code was also bit of a overkill; plus there is precedence for this sort of a thing - https://www.rfc-editor.org/rfc/rfc8685.html#section-3.4.2 > MSL > [...] > * A path P passes through K links {Lpi,(i=1...K)}. > > * A set of paths {P1...Pm} have L links that are common to more > than one path {Lpi,(i=1...L)}. > > Can you double-check the notation here? In the first quoted item it seems > that Lpi indicates the i-th link on path P, but in the second it looks like > Lpi indicates the i-th link in common across paths P1...Pm. I'd suggest > using a different term for the different meaning. > > ACK > MSS > [...] > * A path P passes through K links {Lpi,(i=1...K)} belonging to > unique M SRLGs {Spi,(i=1..M)}. > > What is the relationship between K and M? Is it always true that M <= K? > > One link could have multiple SRLGs, so no! * A set of paths {P1...Pm} have L SRLGs that are common to more > than one path {Spi,(i=1...L)}. > > [same comment about terminology reuse] > > MSN > [...] > * A path P passes through K nodes {Npi,(i=1...K)}. > > * A set of paths {P1...Pm} have L nodes that are common to more > than one path {Npi,(i=1...L)}. > > [same comment about terminology reuse] > > If the OF-list TLV is included in the Association Object, the OF-code > inside the OF Object MUST include one of the disjoint OFs defined in > this document. If this condition is not met, the PCEP speaker MUST > respond with a PCErr message with Error-Type=10 (Reception of an > invalid object) and Error-Value=TBD9 (Incompatible OF code). > > Looking at edge cases, I think that the MUST-level requirements allow for > me > to send an OF-list TLV with two items the first of which is nonsense (i.e., > not one of these three), and the second of which is one of these three. > The > recipient would be obligated to use the first one in the list (by the > previous text "the receiver MUST consider the first OF-code only") despite > it being nonsensical. We should probably try to close that edge case, > though there are several approaches to choose from and I don't have a sense > for what might cause us to prefer one over the other. > > As per Suresh's suggestion, this is changed to - If the OF-list TLV is included in the Association Object, the first OF-code inside the OF Object MUST be one of the disjoint OFs defined in this document. If this condition is not met, the PCEP speaker MUST respond with a PCErr message with Error-Type=10 (Reception of an invalid object) and Error-Value=TBD9 (Incompatible OF code). Which should handle your case and we would return an error. Section 5.4 > > SVEC object. The PCE MUST consider both the objects as per the > processing rules and aim to find a path that meets both of these > constraints. In case no such path is possible, the PCE MUST send a > path computation reply (PCRep) with a NO-PATH object indicating path > computation failure as per [RFC5440]. It should be noted that the > > I would consider reminding the reader that the 'T' bit controls how > strictly > the PCE needs to interpret the DAG constraints, and thus that it's possible > for the PCE to degrade the request without needint to return NO-PATH in > such > cases. > > How about - "The PCE MUST consider both the objects (including the flags set inside the objects) as per the processing rules and aim to find a path that meets both of these constraints." Section 5.5 > > into account the disjointness constraint. Setting P flag changes the > relationship between LSPs to a one-sided relationship (LSP 1 with P=0 > depends of LSP 2 with P=1, but LSP 2 with P=1 does not depend of LSP > 1 with P=0). Multiple LSPs in the same disjoint group may have the P > > nits: "Setting the P flag", "depends on LSP 2" > > I suggest specifying "link disjoint" for at least the example using Figure > 4 > (if not the one using Figure 3 as well), since the paths > PE1->R1->R4->R2->PE2 and PE3->R3->R4->PE4 are not node-disjoint. > > ACK Section 5.6 > > There are some cases where the PCE may need to completely relax the > disjointness constraint in order to provide a path to all the LSPs > that are part of the association. A mechanism that allows the PCE to > fully relax a constraint is considered by the authors as more global > to PCEP rather than linked to the disjointness use case. As a > consequence, it is considered as out of scope of the document. > > I'm not sure how to interpret this. Is it supposed to prevent a PCE from > falling back to "no disjointness" (e.g., all of L/N/S/T are clear in > DISJOINTNESS-STATUS-TLV)? If so, I would have expected this limitation to > be spelled out more clearly much earlier in the document. > > There is a proposal to make an objects as optional to process in stateful messages via https://datatracker.ietf.org/doc/draft-dhody-pce-stateful-pce-optional/, this already exist for stateless messages via RFC 5440. The above text is simply to say that relaxation to "no disjointness" can be handled via a common technique and out of scope of this I-D. > Section 6 > > I suggest also mentioning the security considerations of RFC 7470, as we > have very little control over what information goes in > VENDOR-INFORMATION-TLV. (Not that there's a whole lot of content there, > but > maybe it will get people thinking.) > > I might also consider mentioning again that certain combinations of flags > (notably, the 'T' bit) can result in unsatisfiable requests. But that's > only somewhat a "security" consideration; security aspects only really come > into play for it if someone is spoofing that T bit, and we already > recommend > TLS. > > ACK Section 8.1 > > Range MUST be allowed to be set by the operator. Operator SHOULD be > allowed to set the local policies to define various disjoint > > nit: The operator" > > Section 8.2 > > associations configured or created dynamically. Further > implementation SHOULD allow to view disjoint associations reported by > each peer, and the current set of LSPs in this association. The PCEP > > nit: "Furthermore, implementations" > > Section 8.4 > > Mechanisms defined in this document do not imply any new operation > verification requirements in addition to those already listed in > [RFC5440]. > > We don't think that someone should check that the computed LSPs actually > supply the disjointness properties they're claimed to provide? > > Updated to - Apart from the operation verification requirements already listed in [RFC5440], a PCEP implementation SHOULD provide parameters related to disjoint path computation, such as number of DAG, number of disjoint path computation failures etc. A PCEP implementation SHOULD log failure events (e.g., incompatible Flags). Section 10.2 > > I guess a strict reading of > > https://www.ietf.org/blog/iesg-statement-normative-and-informative-references/ > would require RFC 7470 to be a normative reference, but that doesn't really > seem like the right thing to do for this specific case. > > On the other hand, a RECOMMENDation for RFC 8253's use does feel like it > would place it as a normative reference. > > ACK
- [Pce] Benjamin Kaduk's No Objection on draft-ietf… Benjamin Kaduk via Datatracker
- Re: [Pce] Benjamin Kaduk's No Objection on draft-… Mahend Negi
- Re: [Pce] Benjamin Kaduk's No Objection on draft-… Benjamin Kaduk