Re: [CCAMP] Secdir last call review of draft-ietf-ccamp-rsvp-te-bandwidth-availability-13

tom petch <ietfc@btconnect.com> Fri, 29 March 2019 11:36 UTC

Return-Path: <ietfc@btconnect.com>
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80FC4120251; Fri, 29 Mar 2019 04:36:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.247
X-Spam-Level:
X-Spam-Status: No, score=0.247 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RATWARE_MS_HASH=2.148, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.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 wUeqf3la52Bg; Fri, 29 Mar 2019 04:36:50 -0700 (PDT)
Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-eopbgr150102.outbound.protection.outlook.com [40.107.15.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4990D12024B; Fri, 29 Mar 2019 04:36:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=VhrmWOm1O6wE5A8fl10AOF8lWYUVp+bKAhDnanpsqT4=; b=i2ez9/O7oT76tl/ogIlKn3jDs1ycK05QfvOXvF9hbwQ+30e0FEko6ddhq4jcAArxfqft4RPt/vgzpQRIwbo+FOJWfMc1zysovamymvbd/z5IP1JhKxKNX45ZuBG4tF4EjKB94RFvzKRSJTTPYgQiF6s8UZl2CupoE7Au0rIiKUo=
Received: from DB7PR07MB5562.eurprd07.prod.outlook.com (20.178.46.212) by DB7PR07MB5045.eurprd07.prod.outlook.com (20.177.194.26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1750.13; Fri, 29 Mar 2019 11:36:47 +0000
Received: from DB7PR07MB5562.eurprd07.prod.outlook.com ([fe80::b5b0:a479:a08:54d9]) by DB7PR07MB5562.eurprd07.prod.outlook.com ([fe80::b5b0:a479:a08:54d9%4]) with mapi id 15.20.1750.014; Fri, 29 Mar 2019 11:36:47 +0000
From: tom petch <ietfc@btconnect.com>
To: Sandra Murphy <sandy@tislabs.com>, "Yemin (Amy)" <amy.yemin@huawei.com>
CC: "ccamp@ietf.org" <ccamp@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>, "draft-ietf-ccamp-rsvp-te-bandwidth-availability.all@ietf.org" <draft-ietf-ccamp-rsvp-te-bandwidth-availability.all@ietf.org>, Sandra Murphy <sandy@tislabs.com>
Thread-Topic: [CCAMP] Secdir last call review of draft-ietf-ccamp-rsvp-te-bandwidth-availability-13
Thread-Index: AQHU5iOw1RlCGSGeXUO+py3YX8oOsA==
Date: Fri, 29 Mar 2019 11:36:46 +0000
Message-ID: <02db01d4e623$51e9aee0$4001a8c0@gateway.2wire.net>
References: <154908012600.28521.5714645741731093529@ietfa.amsl.com> <9C5FD3EFA72E1740A3D41BADDE0B461FCFB598CD@DGGEMM528-MBX.china.huawei.com> <3DCE5D1E-DBF1-4293-8FA1-FD6E975E24FC@tislabs.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-clientproxiedby: LO2P265CA0478.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:a2::34) To DB7PR07MB5562.eurprd07.prod.outlook.com (2603:10a6:10:7b::20)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com;
x-ms-exchange-messagesentrepresentingtype: 1
x-mailer: Microsoft Outlook Express 6.00.2800.1106
x-originating-ip: [86.139.215.234]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 11b1e5a9-633d-4818-e793-08d6b43ad30c
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7193020); SRVR:DB7PR07MB5045;
x-ms-traffictypediagnostic: DB7PR07MB5045:
x-ms-exchange-purlcount: 2
x-microsoft-antispam-prvs: <DB7PR07MB504571BB05B9BF319FFBCAE2A05A0@DB7PR07MB5045.eurprd07.prod.outlook.com>
x-forefront-prvs: 0991CAB7B3
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(136003)(366004)(376002)(396003)(39860400002)(346002)(199004)(189003)(37854004)(51914003)(13464003)(6116002)(316002)(6246003)(6436002)(66066001)(53936002)(54906003)(50226002)(68736007)(4326008)(86152003)(6306002)(53946003)(14454004)(9686003)(62236002)(44716002)(25786009)(97736004)(71200400001)(71190400001)(99286004)(4720700003)(5660300002)(84392002)(186003)(66574012)(2906002)(110136005)(486006)(44736005)(76176011)(81686011)(6486002)(14496001)(53546011)(81816011)(256004)(966005)(446003)(52116002)(305945005)(6512007)(81156014)(14444005)(30864003)(8676002)(229853002)(476003)(7736002)(81166006)(386003)(86362001)(1556002)(105586002)(8936002)(26005)(6506007)(478600001)(102836004)(61296003)(106356001)(3846002)(74416001)(7726001)(559001)(579004); DIR:OUT; SFP:1102; SCL:1; SRVR:DB7PR07MB5045; H:DB7PR07MB5562.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:0; MX:1;
received-spf: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: jGtc4j9Sxec82eMB5OwEmM0rtcixEQ6/X/gIUHwvgzNs2wekYCBYoliD0Baf9A9hA4szaNMi5moWLtyqO8NdFldA4z4kvHY5UUJ0Tu4ADcDItNHrX1jUNRnpjjhPt319tusyBb9/iy77FRPhYAVzvf4qRogImLYEiU2uv6qo7Bf7EBPS09fOaVaMbwGAx2+r+SdnohnE/+YTamQajl/oLxwWb3HrPvDBt74CkF/R7UZOqxOkfQ6F85b+PrVptLLdBxvCF+hRoOsKbeJ1trmsqR6fwVFlQRr7oWy/H0ix9fxYV5bfRfkCEAbC9U3KPu+0usxtTAq1QS4D5ePo5Y2Y76Vb92q0Nn9ouo1BadeqtaB6z/2yJ1+wcKiAhwopQGD05pI0OIyfEOnbSJQdE8wMM9h+DRjKIC3n3GoDzdJkO1E=
Content-Type: text/plain; charset="utf-8"
Content-ID: <8C57B162AA30CA47A0E1AF41C2600084@eurprd07.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: btconnect.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 11b1e5a9-633d-4818-e793-08d6b43ad30c
X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Mar 2019 11:36:46.9840 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: cf8853ed-96e5-465b-9185-806bfe185e30
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR07MB5045
Archived-At: <https://mailarchive.ietf.org/arch/msg/ccamp/DymC2f_iy2MzECpbZ48jFUWlc_w>
Subject: Re: [CCAMP] Secdir last call review of draft-ietf-ccamp-rsvp-te-bandwidth-availability-13
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussion list for the CCAMP working group <ccamp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ccamp>, <mailto:ccamp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ccamp/>
List-Post: <mailto:ccamp@ietf.org>
List-Help: <mailto:ccamp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ccamp>, <mailto:ccamp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 29 Mar 2019 11:36:55 -0000

Sandra

On just the question of the reference for floating point, I would draw
your atttention to YANG, RFC7950,which has
   [IEEE754-2008]
              IEEE, "IEEE Standard for Floating-Point Arithmetic",
              IEEE 754-2008, DOI 10.1109/IEEESTD.2008.4610935, 2008,
              <http://standards.ieee.org/findstds/
              standard/754-2008.html>.
There has been a lot of discussion in the IETF OAM arena around this
topic and I would regard that reference as the best considered and
perhaps the most influential..

Tom Petch

----- Original Message -----
From: "Sandra Murphy" <sandy@tislabs.com>;
To: "Yemin (Amy)" <amy.yemin@huawei.com>;
Cc: <ccamp@ietf.org>;; <secdir@ietf.org>;;
<draft-ietf-ccamp-rsvp-te-bandwidth-availability.all@ietf.org>;; "Sandra
Murphy" <sandy@tislabs.com>;
Sent: Thursday, March 28, 2019 11:32 AM
Subject: Re: [CCAMP] Secdir last call review of
draft-ietf-ccamp-rsvp-te-bandwidth-availability-13


> I see that a new version was posted on Mar 6.  I thank the authors for
their attention to my comments and for the explanations for cases where
I was confused.
>
> I have one suggestion.  The authors changed the text to say “floating
point”, but I did not make clear that I think a reference to IEEE 754 is
needed.
>
> I found one reference to an IESG comment during the review of
draft-ietf-isis-pcr
>
> • Jari Arkko: Comment [2016-01-07 04:51 PST]:
> This comment from Suresh Krishnan's Gen-ART review seems relevant:
There is no reference for the format of the Bandwidth fields in Sections
6.3 and 6.4. I am assuming this refers to the Single Precision format
(binary32) from IEEE 754. If so, please add an explicit reference to
this.
>
> So the reference to the IEEE standard has been considered a good idea
in past draft IESG reviews.
>
> I found three RFCs that contained a reference to the IEEE 754
standard.  The first is the RFC that resulted from draft-ietf-isis-pcr
>
> RFC 7813                        IS-IS PCR                      June
2016
>
> 11.2.  Informative References
>
>    [IEEE754]  IEEE, "IEEE Standard for Floating-Point Arithmetic",
>               IEEE 754-2008, DOI 10.1109/IEEESTD.2008.4610935, 2008,
>               <http://standards.ieee.org/findstds/
>               standard/754-2008.html>.
>
> the second is an OSPF RFC
>
> RFC 7471                OSPF TE Metric Extensions             March
2015
>
> 13.1.  Normative References
>
>    [IEEE754]  Institute of Electrical and Electronics Engineers,
>               "Standard for Floating-Point Arithmetic", IEEE Standard
>               754, August 2008.
>
> and the third is a CCAMP RFC:
>
>
> RFC 8330            Availability Extension to OSPF-TE      February
2018
>
> 7.1.  Normative References
>
>    [IEEE754-2008]
>               IEEE, "IEEE Standard for Floating-Point Arithmetic",
>               IEEE 754-2008, DOI 10.1109/IEEESTD.2008.4610935.
>
>
> Note that one reference is informative, two are normative.  The
authors should decide whether the format is a requirement and therefore
the reference should be normative.
>
> In conversation with the RFC-Editor, there are some IEEE requests as
to how the reference should be phrased.  The authors may wish to consult
the RFC-Editor to decide how this reference should be phrased.  There
are evidently considerations of whether you wish this document to follow
the IEEE standard as it changes, or whether you want to point to the
current version explicitly.
>
> Something I did not notice before:
>
> Page 6:
>
>         Optionally, a higher availability bandwidth can be
>         allocated to lower availability request when the lower
>         availability bandwidth cannot satisfy the request.
>
>
> Does this make the order of looking at availability bandwidth requests
important?  If a lower availability requirement bandwidth request is
allocated from the higher availability bandwidth before all higher
availability bandwidth requests are satisfied, might that prevent a
higher availability bandwidth request from being satisfied?
>
> Appendix Page 9 and 10
>
> I am afraid that even after review of the authors' comments and
another time over the Appendix, I still do not understand the table in
the Appendix.  To my reading of page 9 and 10:
>
> 400Mbps (level 3 modulation) is available except for the 52 minutes a
year when the modulation drops to level 2 ==> (525600-52)/525600 =
99.99% of the time 400Mbps is available
>
> 200Mbps (level 2 modulation) is available except for the 26 minutes a
year when the modulation drops to level 1 ==> (525600-26)/525600 =
99.995% of the time 200Mbps is available
>
> 100Mbps (level 1 modulation) is available except for the 5 minutes a
year when the whole system is unavailable ==> (525600-5)/252600 =
99.999% of the time 100Mbps is available.
>
> (There’s another interpretation of your example text - that the
400Mbgp is not available in the light rain that drops the modulation to
level2 -or-  the 26 minutes of heavy rain that drops the modulation to
level 1 -or- when the whole system is unavailable, so 400Mbps is
unavailable 52+26+5 minutes each year, which is more like 99.98%.)
>
> That would make the table say:
>
> Sub-bandwidth (Mbps)   Availability
>
>    ------------------     ------------
>
>    400                    99.99%
>
>    200                    99.995%
>
>    100                    99.999%
>
> Even if I am still am interpreting this incorrectly, I would like to
point out that the text has two statements on page 10 that seem to
conflict:
>
>                                       Then the dropped 100 Mbps
>    bandwidth has 99.995% availability.
>
> and
>
>                                                So the 100 Mbps
>    bandwidth of the modulation level 1 owns the availability of
>    99.999%.
>
> You might want to do the readers a favor and clear up the conflict.
>
>
> Some nits are below.
>
> —Sandy
>
> In light of the RFC-Editor request during the IETF104 plenary on
Wednesday, here are some nits the RFC-Editor would probably catch, but
to make their task easier, I note them here.
>
> Page 3:
>
>                                      When a video application requests
>    for 120 Mbps without bandwidth availability requirement
>
> requests for 120 Mbps —> “makes a request for 120Mbps” or “requests
120Mbps”
> without bandwidth —> without a bandwidth
>
> Page 5:
>
>       Availability (4 octets): a 32-bit floating point number
describes
>
> This would be a good place to put a cite to the IEEE 754 reference.
>
>       the decimal value of availability requirement for this bandwidth
>       request. The value MUST be less than 1and is usually expressed
in
>
> of availability requirement —> “of the availability requirement”
> 1and —> “1 and”
>
> Page 6:
>
>         allocated to lower availability request when the lower
>
> to lower availability request —> to a lower availability request
>
>    When a node receives Availability TLVs which mixed of zero index
and
>
> “which mixed of” —> “which are a mix of"
>
>    several <bandwidth, availability> pairs, but there're are extra
>
> “there’re are” —> “there are”
>
>    bandwidth-TLVs without matching index Availability-TLV, the extra
>
> could be “without matching the index of any Availability-TLV” or
“without any Availability-TLV with a matching index”
>
> Page 7:
>
>                                               RSVP-TE signaling used
>    in GMPLS network.
>
> in GMPLS network —> “in a GMPLS network” or “in GMPLS networks"
>
>
> > On Feb 22, 2019, at 4:58 AM, Yemin (Amy) <amy.yemin@huawei.com>;
wrote:
> >
> > Hi Sandra,
> >
> > Many thanks for the detail review comments, please see reply inline
below.
> > And I’m very sorry for the late reply.
> >
> > BR,
> > Amy
> > -----Original Message-----
> > From: Sandra Murphy [mailto:sandy@tislabs.com]
> > Sent: Saturday, February 02, 2019 12:02 PM
> > To: secdir@ietf.org
> > Cc: ccamp@ietf.org; ietf@ietf.org;
draft-ietf-ccamp-rsvp-te-bandwidth-availability.all@ietf.org
> > Subject: Secdir last call review of
draft-ietf-ccamp-rsvp-te-bandwidth-availability-13
> >
> > Reviewer: Sandra Murphy
> > Review result: Has Issues
> >
> > I have reviewed this document
draft-ietf-ccamp-rsvp-te-bandwidth-availability
> > as part of the security directorate’s ongoing effort to review all
IETF documents being processed by the IESG. These comments were written
primarily for the benefit of the security area directors.  Document
editors and WG chairs should treat these comments just like any other
last call comments.
> >
> > This draft provides a new TLV for the Ethernet SENDER_TSPEC object
that will carry availability requirements for RSVP-TE signaling of GMPLS
LSPs.
> >
> > The draft is thorough.  I do have some comments.  I reviewed the
normative references RFCs 2205, 3209, 3473, 6003, as well as RFC3945 and
RFC5920.  I can’t claim that I understood everything in that stack, so
the following could easily be wrong.
> >
> > Computing the LSP path:
> >
> > Page 4, section 2 discusses obtaining network topology, calculating
the LSP route, RFC8330’s extensions for availability in OSPF TE LSA
messages.  Does this draft assume that this extension will always be
used with an EXPLICIT_ROUTE object?  Is this draft not applicable
without that explicit LSP route calculation?
> > [Amy] No, there's no assumption that the extension can be only used
with an EXPLICIT_ROUTE object.  The node who obtains network topology,
calculates the LSP route, could be a source node and intermediate nodes.
> > Availability TLV vs CLASSTYPE objects:
> >
> > The definition in RFC6003 of the Bandwidth Profile TLV has certain
constraints on the values of the Index:
> >                          The Index field value MUST correspond to at
least one
> >       of the Class-Type values included either in the CLASSTYPE
object
> >       [RFC4124] or in the EXTENDED_CLASSTYPE object [MCOS].
> >
> > I am not certain if this means that the presence of an Ethernet
SENDER_TSPEC Object with a Bandwidth Profile TLV means there must be a
CLASSTYPE object in the RSVP-TE message as well, or that the Index field
values are taken from the set of defined Class-Type values.
> >
> > But if the first, does this induce requirements by inclusion of the
Availability TLV that these other CLASSTYPE objects must be included as
well?
> > Or are you intending to update RFC6003 to eliminate that constraint?
If the second, does the RFC6003 constraint also constrain the index
values used in the Availability TLV?  Should that be mentioned?  (Or am
I just confused?)
> > [Amy] It’s the second case. The RFC6003 constraint should also apply
to the index values used in the Availability TLV. The current text
states that “having the same value of Index field”, which implies the
same constraint.
> >
> > Bandwidth TLV to Availability TLV association:
> >
> > Page 4, Section 3.1 says
> >
> >       When the Availability TLV is included, it MUST be present
along
> >       with the Ethernet Bandwidth Profile TLV. If the bandwidth
> >       requirements in the multiple Ethernet Bandwidth Profile TLVs
have
> >       different Availability requirements, multiple Availability
TLVs
> >       SHOULD be carried. In such a case, the Availability TLV has a
one
> >       to one correspondence with the Ethernet Bandwidth Profile TLV
by
> >       having the same value of Index field. If all the bandwidth
> >       requirements in the Ethernet Bandwidth Profile have the same
> >       Availability requirement, one Availability TLV SHOULD be
carried.
> >       In this case, the Index field is set to 0.
> >
> > I find that the description is not clear in all cases.  I found a
message in the working group discussion of this association that the
association is either “n:n” or “n:1”.  I think this description sounds
more like n 1:1 associations
> > or a  n:1 association.   Is that what is intended?  Can the
associations be
> > mixed in the same message?  Suppose there were 3 Bandwidth TLVs that
needed the same availability and one that had a different availability
need, could there be 3 Bandwidth TLVs with index 0 and one
Availability-TLV with index 0 and also a Bandwidth TLVs - Availability
TLV pair with matching index values?
> > [Amy] Thanks for looking into the past discussion. The intension was
n*(1:1) association or n:1 association. It was not so accurate by using
“n:n” association in the past.
> > Regarding the example you list, if the four Bandwidth TLVs are sent
in the same message, it’s better to use four different index values as
they are “multiple Ethernet Bandwidth Profile TLVs have different
Availability requirements”.
> > Of course what you proposed could also work technically.
> >
> > error checking:
> >
> > Other documents in the references (RFC2205, 3209, 3473, 6003, etc)
have made a point of explicitly describing the error handling - when
PathErr and ResvErr and Notify messages are sent, to whom, the error
codes, the error value sub-codes, etc.  I don’t see that here for the
bandwidth-tlv-to-availability-tlv associations.
> > [Amy] Thanks for the comment, I agree the error process should be
clearer.
> > Is a mix of index-zero and index-non-zero
bandwidth-tlv-to-availability-tlv associations (like above) an error? is
the message dropped?  is an error sent?
> > if the message is not dropped, are any of the bandwidth-tlv,
availability-tlv associations retained?
> > [Amy] The message MAY be ignored and SHOULD NOT be propagated.
> > If there are availability-tlvs with non-zero indexes with no
matching index value among the bandwidth-tlvs, that surely is an error?
Is the message dropped?  Or is the availability tlv dropped?  Is a
PathErr/ResvErr message sent?
> > [Amy] yes, this is an error. It’s preferred to drop the availability
tlv.
> > Suppose all availability-tlvs have a matching (zero or non-zero)
index value among the bandwidth-tlvs, but there are extra bandwidth-tlvs
(no availability-tlv with a matching index value).  Is that an error?
Are the extra bandwidth-tlvs dropped? ignored? propagated?
> > [Amy]The extra bandwidth-tlvs MAY be ignored and SHOULD NOT be
propagated.
> > (RFC3209 has several cases where there might be extra objects or
sub-objects and the language is “can be/MAY be/SHOULD be/are ignored and
SHOULD NOT be /are not/need not be propagated” )
> >
> >
> > multiplicity:
> >
> > RFC3209 says it does not apply to multicast, but it does talk about
multiple parallel LSP tunnels between two nodes, and about
multipoint-to-point LSPs for WF and SE style reservations when there are
multiple senders, and about the merging rules of WF reservations.  Does
availability work in those style reservations?
> > [Amy] Considering that the traffic from senders is more likely to be
concurrent and independent, the availability TLV can be limited to Fixed
Filter (FF) Style only.
> > availability vs “variable discrete bandwidth”:
> >
> > I believe I understood the discussion of the need to signal
availability requirements in order for the system to determine when an
LSP was feasible.  I can dimly understand that there might be links have
“variable discrete bandwidth”.  Section 2 says “The Availability TLV can
be applicable to any kind of physical links with variable discrete
bandwidth, such as microwave or DSL.”
> > Why not other link types? Do only “variable discrete bandwidth”
links support availability?
> > [Amy] To our current knowledge, only“variable discrete bandwidth”
links support availability.
> >
> > calculating availability:
> >
> > In page 9, Appendix A:
> >
> > Perhaps I don’t understand how the availability metric is used.  In
the
> > following:
> >
> >    On a sunny day, the modulation level 3 can be used to achieve 400
> >    Mbps link bandwidth.
> >
> >    A light rain with X mm/h rate triggers the system to change the
> >    modulation level from level 3 to level 2, with bandwidth changing
> >    from 400 Mbps to 200 Mbps. The probability of X mm/h rain in the
> >    local area is 52 minutes in a year. Then the dropped 200 Mbps
> >    bandwidth has 99.99% availability.
> >
> > I would say that the 400Mbps bandwidth is available whenever it is
not raining.
> > It lightly rains 52 min year, which means it is not raining 99.99%
of the time, so the 400Mbps availability is 99.99%.  The 200Mbps is
available during that 52 min, so 99.99% is not the 200Mbps availability.
Right?
> >
> > The analogous comment applies to the next two paragraphs.
> >
> > Does that explain why the table shows the 100Mbps bandwidth having
two different availabilities?
> > [Amy]Your understanding is also correct. That is just a different
way to present the result. Take the values from the table, 100Mbps with
99.995% and 100Mbps with 99.999% can be also considered as bandwidth
with 99.99% availability.
> > Thus it will result the total bw with 99.99% availability =
200+100+100=400Mbps
> >
> >
> > security:
> >
> > The draft (*) security consideration points to RSVP-TE, but without
an RFC reference, and to RFC5920.  Because this is a GMPLS related
feature, it should refer to the GMPLS extensions to RSVP-TE in RFC3473.
As an extension to RFC6003, it could refer to that RFC’s security
considerations section, but that only gets the reader to RFC3473,
RFC3209, and RFC5920.
> >
> > The security considerations for RSVP-TE itself (RFC3209) points to
RFC2205.
> > RFC2205 defines an Integrity object (defined in RFC2747) that
carries a keyed cryptographic digest based on a shared key, providing
hop-by-hop protection between two RSVP nodes.  However, PATH messages
are directed toward the traffic destination address, not the next RSVP
node.  There could be clouds of non-RSVP nodes between two RSVP nodes
that the PATH encounters.  This makes it difficult to share a key
between individual pairs of RSVP nodes, and could motivate operators to
configure the same key in large numbers of RSVP nodes.
> >
> > RFC3473 points to RFC2747’s protection of RSVP messages.  It also
notes that it introduces a Notify message that is not sent to the
traffic destination address but instead to a node that requested
notification.  One transmission option is that the NOTIFY is
encapsulated in an IP packet and forwarded directly to the requesting
node.  That complicates the Integrity object protection, unless the
shared key is widely shared.
> >
> > RFC3945 notes that authentication in GMPLS systems may use the
authentication mechanisms of the component protocols, pointing to
RFC2747 (as well as others for LDP, LMP, etc that don’t apply here).
> >
> > RFC5920 discusses threats, attacks, and protections for MPLS/GMPLS
data and control planes.  Section 7.1.2 in particular talks about
“Control-Plane Protection with RSVP-TE”, and could be mentioned here
explicitly.  It talks about network border configuration to limit
external attacks, and mentions
> > RFC2747 authentication protections, making some of the same points
about non-RSVP clouds and shared keys configuration.  It also points to
RFC4230, which is a very detailed look at RSVP security, and probably
deserves to be mentioned here.
> >
> > So all told, at the end of all the reference chains, the only
defined authentication and integrity protection in 2205, 3209, and 3473
is based on shared keys that are very difficult to configure with fine
granularity.
> >
> > However, as was said in reply to a different MPLS related draft
review
> > yesterday:
> >
> >     The MPLS network is often considered to be a closed network such
that
> >     insertion, modification, or inspection of packets by an outside
party is
> >     not possible.
> >
> > So maybe that is accepted as sufficient in deployment.
> >
> > MPLS documents are also typically granted an exception from more
rigorous security requirements because MPLS is used only within one
routing domain / ISP / provider / etc, under a single administrative
control, so errors made would not be global in impact.  In particular,
errors that might result from one legitimate but
faulty/mis-configured/subverted/malicious MPLS node should not propagate
out to the general Internet.  (**)
> > [Amy] Thanks for the detail explanation on the security
consideration, it’s quiet educational. As the operating environment of
GMPLS is similar to MPLS network, we will adopt the similar text.
> >
> > Nits:
> >
> > floating numbers
> >
> > Page 5, Section 3.1, says “a 32-bit floating number”.  I believe you
mean a floating-point number.  I checked other IETF RFCs (e.g.,
RFC8330), and it is common to mention the IEEE 754-2008 standard when
including a floating point value in the spec.
> >
> > But is a floating point value needed?  The draft says that the
values are typically in a small set of known values.  The intro sounds
like a small set of classes are used for “efficient planning”.  Just
curious.  OTOH, RFC8330 uses floating point, and the ITU documents’
calculation of availability make it seem like full floating point is
needed.
> > [Amy] will update to “floating-point number”.
> >
> > the Availability TLV format:
> >
> > page 5, section 3.1 says:
> >
> >                                                The Availability TLV
has
> >    the following format:
> >
> >        0                   1                   2                   3
> >        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0
1
> >
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >       |    Index      |                 Reserved
|
> >
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >       |                          Availability
|
> >
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >
> >                           Figure 1: Availability TLV
> >
> > I presume that this is just the Value portion of the TLV format that
is defined for the Ethernet SENDER_TSPEC Object in Section 4 of RFC6003.
> > [Amy] Yes, it is.
> >
> > Page 1, Abstract:
> >
> >    typically used for describing these links when during network
> >    planning
> >
> > “when during” - is that deliberate?  It sounds redundant, maybe due
to editing.
> > Or maybe it was supposed to be “when doing”?
> > [Amy] Will update to “when doing”.
> >
> >    signaling. This extension can be used to set up a Generalized
Multi-
> >    Protocol Label Switching (GMPLS) Label Switched Path (LSP) using
the
> >    Ethernet SENDER_TSPEC object.
> >
> > not sure - what is using the SENDER_TSPEC - the LSP or this
extension?
> > [Amy] How about change to “in conjunction with SENDER_TSPEC”.
> >
> > Page 3, Section 1:
> >
> >    bandwidth availability. For example, the bandwidth with 99.999%
> >    availability of a link is 100 Mbps; the bandwidth with 99.99%
> >    availability is 200 Mbps.
> >
> > maybe:
> >
> >    bandwidth availability. Suppose, for example, the bandwidth with
99.999%
> > [Amy] will update the text.
> >
> > Page 5, section 3.2:
> >
> >    TLVs and one or more Availability TLVs. Each Ethernet Bandwidth
> >    Profile TLV corresponds to an availability parameter in the
> >    Availability TLV.
> >
> > … “in an Availability TLV”? or “in the associated Availability TLV”?
There’s more than one.
> > [Amy] will update to “in the associated Availability TLV”.
> >
> > Page 6, section 3.2
> >
> >         link), it SHOULD reserve the bandwidth resource from each
> >
> > “it” -> “the node”
> >
> >        this LSP. Optionally, the higher availability bandwidth can
be
> >
> > “the higher” -> “a higher”  (there’s more than one, right?)
> >
> >         request cannot be satisfied, it SHOULD generate PathErr
message
> >
> > “it” -> “the node”
> >
> >    generate PathErr message with the error code "Extended Class-Type
> >
> > “PathErr” -> “a PathErr” or “PathErr messages”
> > [Amy] will update the draft accordingly.
> > postscripts:
> >
> > (**) [[[ I will note that RFC3209 includes an AS number subject
among the subobjects of the EXPLICIT_ROUTE object.  With the idea that
you might set up explicit routes that go through multiple ASNs.  Ouch.
I know there are providers who have different ASNs under single
administrative control, from acquisitions or business use cases, but
this just makes it possible for an explicit route for an LSP to be
misconfigured to include your (external) neighbor ASN.  And RFC5920
talks about “ASBR-ASBR communication for inter-AS LSPs”.  Better have
good outbound filters on your border routers. ]]]
> >
> > (*)As is typical for specifications that extend other published
RFCs, this draft says it “does not introduce any new security
considerations”.
> >
> > <begin soapbox> In general, I am skeptical of extension drafts that
make such claims.  Surely the existing security considerations should be
examined to see how they apply to this new feature or object being
introduced?  Do current protections adequately protect the new
feature/object?  Does the new feature/object carry new information,
produce new behaviors?  etc. But this is so very common I could hardly
request that more be said here. Just saying. <end
> > soapbox>
> > [Amy] Thanks again for the detail review.
>
> _______________________________________________
> CCAMP mailing list
> CCAMP@ietf.org
> https://www.ietf.org/mailman/listinfo/ccamp
>