Telechat Review of draft-ietf-ccamp-rsvp-te-bandwidth-availability-14
review-ietf-ccamp-rsvp-te-bandwidth-availability-14-secdir-telechat-murphy-2019-04-08-00

Dear all,

I agreed that IEEE754 should be referenced.  I also talked to RFC editors about
the preferred format, they recommend the following format:
   [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>.

Regarding the appendix, Sandy and I had a talk during the IETF meeting. It's
agreed that the text in the appendix will be updated to avoid ambiguous. Also
the nits will be fixed.

Thank again for Sandy and Tom's comments.

BR,
Amy
-----Original Message-----
From: tom petch [mailto:ietfc@btconnect.com]
Sent: Friday, March 29, 2019 7:37 PM
To: Sandra Murphy <sandy@tislabs.com>; 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> Subject: Re: [CCAMP] Secdir last call review of
draft-ietf-ccamp-rsvp-te-bandwidth-availability-13

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 >