Re: [Teas] Genart last call review of draft-ietf-teas-rsvp-te-scaling-rec-06

[Vishnu Pavan Beeram <[e-mail]>]

Lou,
Thanks for the response. I think that settles the "update" debate.

Elwyn, Hi!
Are you satisfied with my other responses? I'll submit a new revision as
agreed in my responses.

Regards,
-Pavan

On Fri, Oct 6, 2017 at 3:31 PM, Lou Berger <[e-mail]> wrote:

> Hi Pavan,
>
> On 10/05/2017 07:44 AM, Vishnu Pavan Beeram wrote:
> > Lou, Hi!
> >
> > Responses inline (prefixed PB).
> >
> > Regards,
> > -Pavan
> >
> > From: Lou Berger <[e-mail] <mailto:[e-mail]>>
> > Date: Thursday, October 5, 2017 at 6:41 AM
> > To: "[e-mail] <mailto:[e-mail]>"
> > <[e-mail] <mailto:[e-mail]>>, Elwyn Davies
> > <[e-mail] <mailto:[e-mail]>>
> > Cc: "[e-mail] <mailto:[e-mail]>" <[e-mail]
> > <mailto:[e-mail]>>,
> > "[e-mail]
> > <mailto:[e-mail]>"
> > <[e-mail]
> > <mailto:[e-mail]>>,
> > "[e-mail] <mailto:[e-mail]>" <[e-mail]
> > <mailto:[e-mail]>>, ietf <[e-mail] <mailto:[e-mail]>>
> > Subject: Re: [Teas] Genart last call review of
> > draft-ietf-teas-rsvp-te-scaling-rec-06
> >
> > Hi Pavan,
> >
> > WRT if this document updates rfc2961:
> >
> > I don't have a strong opinion on or objection to this document updating
> > rfc2961.  To have this document be an update, I do think we and it need
> > to be clear on what exactly is being updated in 2961. After rereading
> > both it's unclear to me what you see is being updated. As best I can
> > see, this document basically relates to 2961 in that it says (a) use the
> > reliable message delivery defined in 2961 and (b) restates that 2205
> > refresh processing of path and resv messages still applies after a rapid
> > retry period expires and (c) sending acks moves from recommended to
> > required.
> >
> > What did I miss?
> >
> > FWIW I think (a) and (c) are requirements of this document not 2961 and
> > (b) seems like an informative statement that the basic refresh
> > processing rules of rfc2205 still apply.
> >
> > --
> > [PB] This is all about how we interpret (b). RFC2961 doesn’t explicitly
> > state what happens the rapid retry period expires. The current draft
> > explains what needs to be done. Does this warrant an official update to
> > RFC2961?
>
> The RFC doesn't generally review unmodified RFC2205 processing, nor has
> that been the normal practice when defining RSVP extensions.  An
> informative statement in this draft certainly would do no harm if you
> feel that it is needed, but I don't think it raises to the level of an
> update.
>
> Thanks,
> Lou
>
>
> > —
> >
> > Thanks
> > Lou
> >
> > On October 1, 2017 9:14:15 AM Vishnu Pavan Beeram <[e-mail]
> > <mailto:[e-mail]>> wrote:
> >
> >> Elwyn, Hi!
> >>
> >> Please see inline for responses.
> >>
> >> Regards,
> >> -Pavan
> >>
> >> On Fri, Sep 29, 2017 at 1:34 PM, Elwyn Davies <[e-mail]
> >> <mailto:[e-mail]>> wrote:
> >>
> >>
> >>
> >>     Hi, Pavan.
> >>
> >>     I've checked through the changes in -07 and I think all is good as
> >>     regards fixing the 'major issue', restucturing s2 and fixing the
> >>     nits - thanks.
> >>
> >>
> >> [Pavan] Great!
> >>
> >>
> >>     Looking at the IESG comments I think you have covered most of
> >>     them  except it would be good to put a pointer to Appendix A into
> >>     the intro of s2.
> >>
> >>     With reference to Appendix A(d), it would be helpful to s/periodic
> >>     retransmission interval/Periodic Retransmission Interval/ and
> >>     possibly give it a name (Rpri or some such)  in s2.3 and Appendix
> >>     A(d).  Adding the name of the interval after "retransmission of
> >>     these on a slower timer" migt mak it clearer also.
> >>
> >>
> >> [Pavan] Ok. We'll add a pointer to the Appendix and also find a short
> >> form for the periodic retransmission interval.
> >>
> >>
> >>     However,  I think you still need to address all three of the minor
> >>     issues:
> >>     - Capability object:  A 'basic' implementation of RFC 2209/RFC3209
> >>     will not include the RFC5063 extensions.
> >>
> >>
> >> [Pavan] I think you meant RFC2205 and not RFC2209.
> >>
> >>     I think you should therefore make it explicit that a prerequisite
> >>     for your extensions is an implementation of the Capability object
> >>     as specified in RFC5063 (my proposal for s3) , making it clear
> >>     that this does not require any of the other functionality of RFC
> >>     5063, especially no support for the S bit in the Capabilities.
> >>
> >>
> >> [Pavan] I'm not really sure that "Capability Object" needs a separate
> >> prerequisite section. I'll let the Document-Shepherd and our AD take a
> >> call on this. Please note that the document also talks about using
> >> Node-ID hellos from RFC4558. Would "Node-Hellos/RFC4558" also then
> >> need a separate prerequisite section? We added a separate section for
> >> RFC2961 because there is a need to explicitly clarify the usage of
> >> certain 2961 procedures. With "Capability Object" and "Node Hellos",
> >> there isn't anything (IMHO) that needs to be explicitly clarified. We
> >> could just add a statement in Section 4.1 saying that you don't need
> >> to set any other flags. Would that address your concern about the
> >> ambiguity regarding the "Graceful Restart" bits?
> >>
> >> OLD
> >>    An implementation supporting the RI-RSVP technique
> >> MUST set a new
> >>    flag "RI-RSVP Capable" in the CAPABILITY object signaled in Hello
> >>    messages.
> >> NEW
> >>
> >>  An implementation supporting the RI-RSVP technique MUST set a new
> >>    flag "RI-RSVP Capable" in the CAPABILITY object signaled in Hello
> >>    messages. This MAY be the only flag set in the object.
> >>
> >>
> >>     -  Your response regarding what happens if a peer initially
> >>     acknowledges that it supports the new capabilities by setting the
> >>     I/F bits in the Capability and sends some messages with the
> >>     Refresh-Reduction-Capable bit set, but then stops setting the
> >>     Refresh-Reduction-Capable bit doesn't really address the problem.
> >>      Would this mean that the receiver should assume that the peer can
> >>     no longer support the extensions?
> >>
> >>
> >> [Pavan] Yes.
> >>
> >>     Is this a permanent state or could the peer start setting the
> >>     Refresh-Reduction-Capable bit again and restore initial
> >>     functionality - or should this just not be allowed.
> >>
> >>
> >> [Pavan] The peer can set the bit again and restore the functionality.
> >>
> >>     I think you need to think through what happes in the various
> >>     possible cases and explain what an implementation should do in
> >>     each case.
> >>
> >>
> >> [Pavan] There are only two possibilities -- Is the functionality
> >> enabled on the peer or is it not? If the functionality is enabled, the
> >> implementation does everything that is specified as required for the
> >> given technique. If it is not enabled, then the implementation doesn't
> >> employ the technique and just behaves like it does today. We'll try
> >> and add some text to make this obvious.
> >>
> >>
> >>     - So, I have done my homework and checked back on what happens
> >>     when there is no acknowledgement of refreshes. The relevant
> >>     parameter is the cleanup time.  However, this leaves us with a
> >>     problem.. the cleanup time is typically set as a multiple of the
> >>     refresh interval (9 times seems to be the default) - indeed I see
> >>     that the interface configuration on a Juniper router (!) actually
> >>     sets it by asking for the multiple rather than an absolute value.
> >>     Wth the new dispensation in ths document, there are two time
> >>     periods involved:  I think you do need to respecify how to
> >>     calculate a sensible cleanup interval, and note that the
> >>     retransmissions will then halt after this interval.
> >>
> >>
> >> [Pavan] I think you are confusing this with the "setup retry" timer
> >> (which comes into play when you signal the PATH setup of an LSP
> >> instance and don't get a RESV back). Please go through
> >> https://tools.ietf.org/html/draft-ravisingh-teas-rsvp-setup-retry-01
> >> <https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__tools.ietf.org_html_draft-2Dravisingh-2Dteas-2Drsvp-
> 2Dsetup-2Dretry-2D01&d=DwMDaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-
> ndb3voDTXcWzoCI&r=CFHVfW0WsgxSqM6wTJiWE5evUJAdlUl1fm7E0WVbiS8&m=k7e-
> cloxf90XW9b_KRgpp7fxJRT4Q-f-_Nor0jTe8fg&s=XXwwGPXiCQhVIgNDbiHxKEuHs1fkmM
> oiGQsHcQ33ZQE&e=>
> >> for a detailed account of setup retry timer, issues associated with it
> >> and recommended practices. The staged retransmission (Section 2.3)
> >> that comes into play when there is no ACK is different from what you
> >> are alluding to -- it is meant for any message seeking ACK (not just
> >> PATH). This is very specific to the exponential back-off procedure
> >> discussed in Section 6 of RFC2961. As per RFC2961, the rapid
> >> retransmissions stop after we reach a certain retry limit. In Section
> >> 2.3, we are clarifying what needs to be done after this Retry limit is
> >> reached --- the recommendation is to fall back on a not so rapid
> >> retransmission interval. As a I said in my previous email, this needs
> >> to be done until either an ACK is received or the corresponding state
> >> is torn down.
> >>
> >>
> >>     Does this last modification constitute an update of RFC 2209?  I
> >>     am not sure -consult your AD!
> >>
> >>
> >> [Pavan] RFC2209 is an informational document that provides guidance on
> >> the various data-models and procedures needed for an implementation to
> >> be RFC2205 compliant. Most of the content in RFC2209 is outdated
> >> (imho). No one has had the inclination over the years to update this
> >> and we don't intend to do this either.
> >>
> >> [Pavan] Reading through the various questions/comments from the IESG,
> >> I'm convinced that this document needs to formally update RFC2961.
> >> We'll go ahead and do that if the shepherd and our AD have no
> objections.
> >>
> >>
> >>
> >>     Regards,
> >>     Elwyn
> >>
> >>     Sent from Samsung tablet.
> >>
> >>     -------- Original message --------
> >>     From: Vishnu Pavan Beeram <[e-mail]
> >>     <mailto:[e-mail]>>
> >>     Date: 28/09/2017 03:48 (GMT+00:00)
> >>     To: Elwyn Davies <[e-mail]
> >>     <mailto:[e-mail]>>
> >>     Cc: [e-mail] <mailto:[e-mail]>,
> >>     [e-mail]
> >>     <mailto:[e-mail]>, ietf
> >>     <[e-mail] <mailto:[e-mail]>>, [e-mail]
> >>     <mailto:[e-mail]>
> >>     Subject: Re: [Teas] Genart last call review of
> >>     draft-ietf-teas-rsvp-te-scaling-rec-06
> >>
> >>     Elwyn, Hi!
> >>
> >>     Thanks for the detailed review and the text suggestions. We just
> >>     posted a new revision (-07) to address the concerns listed below.
> >>     Please go through the new diffs
> >>     (https://www.ietf.org/rfcdiff?url2=draft-ietf-teas-rsvp-te-
> scaling-rec-07
> >>     <https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_rfcdiff-3Furl2-3Ddraft-2Dietf-2Dteas-
> 2Drsvp-2Dte-2Dscaling-2Drec-2D07&d=DwMDaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-
> ndb3voDTXcWzoCI&r=CFHVfW0WsgxSqM6wTJiWE5evUJAdlUl1fm7E0WVbiS8&m=k7e-
> cloxf90XW9b_KRgpp7fxJRT4Q-f-_Nor0jTe8fg&s=xuSuAQ7BlTuE-ue-
> 3t5WtAzMMA9cBuBNzk4iM7yoTHs&e=>)
> >>     and let us know if additional changes are required.
> >>
> >>     Please see inline for further responses (prefixed VPB).
> >>
> >>     Regards,
> >>     -Pavan
> >>
> >>     On Fri, Sep 22, 2017 at 6:06 PM, Elwyn Davies
> >>     <[e-mail] <mailto:[e-mail]>> wrote:
> >>
> >>         Reviewer: Elwyn Davies
> >>         Review result: Not Ready
> >>
> >>         I am the assigned Gen-ART reviewer for this draft. The General
> >>         Area
> >>         Review Team (Gen-ART) reviews all IETF documents being processed
> >>         by the IESG for the IETF Chair.  Please treat these comments
> just
> >>         like any other last call comments.
> >>
> >>         For more information, please see the FAQ at
> >>
> >>         <https://trac.ietf.org/trac/gen/wiki/GenArtfaq
> >>         <https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__trac.ietf.org_trac_gen_wiki_GenArtfaq&d=DwMDaQ&c=
> HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=
> CFHVfW0WsgxSqM6wTJiWE5evUJAdlUl1fm7E0WVbiS8&m=k7e-
> cloxf90XW9b_KRgpp7fxJRT4Q-f-_Nor0jTe8fg&s=7EVfFwYHvGi6M8T035d7tGPQVwgnEJ
> q_TzB3RddVx2Q&e=>>.
> >>
> >>         Document: draft-ietf-teas-rsvp-te-scaling-rec-06
> >>         Reviewer: Elwyn Davies
> >>         Review Date: 2017-09-22
> >>         IETF LC End Date: 2017-09-22
> >>         IESG Telechat date: 2017-09-28
> >>
> >>         Summary: Not ready, primarily because the title and
> >>         presentation give the
> >>         impression that the content is really a BCP when it isn't.
> >>         This conceals the
> >>         considerable amount of tweaking of RFC 2961 functionality and
> >>         addition of new
> >>         RSVP Capabilities described in the document.  There are also a
> >>         couple of minor
> >>         issues that need to be sorted out.
> >>
> >>         Major issues:
> >>         Title and way proposals are presented:  The document defines
> >>         two new
> >>         'capabilities' for RSVP-TE and is indeed (as specified in the
> >>         document header)
> >>         correctly intended for Standards Track status.  However the
> >>         title and the whole
> >>         of the meat of the document in Section 2 presents the proposals
> as
> >>         'recommendations' which says to me that I am expecting a BCP
> >>         where a profile of
> >>         available options from existing standards is recommended as
> >>         the best choice for
> >>         implementation and deployment.  In my opinion, the title would
> >>         be better as
> >>         something like "Additional Capabilities Designed to Improve
> >>         the Scalability of
> >>         RSVP-TE Deployments".  Whilst the proposals are based on the
> >>         techniques in RFC
> >>         2961, the document *requires* the implementor to conform to
> >>         rules that were
> >>         optional and constrains configurable values to different
> >>         ranges in order to be
> >>         able to deliver the capabilities defined in the document as
> >>         well as defining
> >>         new RSVP extensions modifying some of the behaviour defined in
> >>         RFC 2961.  Thus
> >>         although some of the rules could be met by choosing particular
> >>         values within
> >>         the RFC 2961 set, the use of MUST, tweaking of functionality
> >>         and variation of
> >>         ranges takes it well beyond a set of recommendations for RFC
> >>         2961 options
> >>         selections.  In view of this Section 1 needs to be written as
> >>         an introduction
> >>         to the definitions of the new capabilities rather than
> >>         advocacy for selection
> >>         of RFC 2961 options and the implication that the techniques
> >>         mentioned in the
> >>         last paragraph of s1 are just a matter of selecting a profile
> >>         of option values.
> >>          In actuality new protocol values are introduced and ss2.2 and
> >>         2.3 define novel
> >>         extensions to RSVP beyond what is available for RFC 2961 and
> >>         requiring
> >>         modification to basic RFC 2961 functionality..
> >>
> >>
> >>     [VPB] We changed the title to "Techniques to Improve the
> >>     Scalability of RSVP-TE Deployments". We also tweaked the text in
> >>     the introduction section as suggested. Please see if the new set
> >>     of diffs address the comment above.
> >>
> >>         Minor issues:
> >>         Interaction with RFC 5063:  The document does not explicitly
> >>         state that an
> >>         implementation would need to support (at least) the extra
> >>         capability obect
> >>         defined in s4.2 of RFC 5063.  Some words about interaction
> >>         with RFC 5063 are
> >>         probably required in that s4.2.1 of RFC 5063 rather assumes
> >>         that if there is a
> >>         capability object, by default its S bit will be set.
> >>
> >>
> >>     [VPB] The CAPABILITY object in RFC5063 is meant for generic use
> >>     and can be used even when there are no Graceful Restart extensions
> >>     in play (even when no GR flags are set). As far as we can tell,
> >>     there is nothing in RFC5063 that precludes this. We added a
> >>     reference to RFC5063 when the new Capability flags are introduced.
> >>     Would this be sufficient to address this concern?
> >>
> >>
> >>
> >>         Behaviour if a node stops setting Refresh-Reduction-Capable
> >>         bit:  The last para
> >>         of s2 in RFC 2961 discusses behaviour if a node stops setting
> >>         this bit in
> >>         messages.  What would happen with the extensions defined in
> >>         this document if
> >>         this happened while either of the extensions is in use?  As a
> >>         matter of
> >>         interest, if a peer offers the capabilities defined in this
> >>         draft, is it
> >>         possible or sensible for it to stop setting the
> >>         Refresh-Reduction-Capable bit
> >>         without stopping offering the extensions?
> >>
> >>
> >>     [VPB]  If a peer sets the I or F bit in the CAPABILITY object but
> >>     does not set the Refresh-Reduction-capable bit, then the
> >>     corresponding functionality ("RI-RSVP" or "Per-Peer Flow-Control")
> >>     is not activated for that peer. In other words, resetting the
> >>     Refresh-Reduction-Capable bit immediately makes the node incapable
> >>     of supporting the two capabilities discussed in this document.
> >>     This is covered in Sections 3.1 and 4.1 ( -07 version).
> >>
> >>
> >>         s2.1.3, para 2: As specified, it appears that the 'slower
> >>         timer' transmission
> >>         of Path and Resv messages can go on indefinitely if no ack
> >>         arrives.  What puts
> >>         an end to this repetition?  [It may be that I have forgotten
> >>         how basic RSVP
> >>         works, but since this is altering the behaviour it would be
> >>         good to explain how
> >>         it terminates, and whether this requires any additional
> >>         modification to timers.]
> >>
> >>
> >>     [VPB]  There is nothing new about Path and Resv messages getting
> >>     transmitted indefinitely (this is normal soft-state signaling
> >>     behavior) -- all that this section does is discuss how these
> >>     transmissions are paced in the absence of an ack. The slower timer
> >>     transmission will go on until either an ack is received (at which
> >>     point the regular "refresh interval" comes into play) or the
> >>     corresponding LSP instance state is torn down.
> >>
> >>
> >>         Nits/editorial comments:
> >>         Abstract: RSVP-TE is not a 'well-known' abbreviation:
> >>         s/RSVP-TE/RSVP Traffic
> >>         Engineering (RSVP-TE)/
> >>
> >>
> >>         Abstract and s1, first para:  This para is not future proof.
> >>         Suggest:
> >>         OLD:
> >>            The scale at which RSVP-TE [RFC3209] Label Switched Paths
> >>         (LSPs) get
> >>            deployed is growing continually and there is considerable
> >>         onus on
> >>            RSVP-TE implementations across the board to keep up with this
> >>            increasing demand in scale.
> >>         NEW:
> >>            At the time of writing, networks which utilise RSVP Traffic
> >>         Engineering
> >>            (RSVP-TE) [RFC3209] Label Switched Paths (LSPs) are
> >>         encountering limitations
> >>            in the ability of implementations to support the growth in
> >>         the number of LSPs
> >>            deployed.  This document defines two additional RSVP-TE
> >>         extensions that
> >>            are intended to reduce the number of messages needed to
> >>         maintain RSVP-TE
> >>            soft state in routers and hence allow implementations to
> >>         support larger
> >>            scale deployments.
> >>         ENDS
> >>         Note:  Omit reference from Abstract.
> >>
> >>
> >>     [VPB] Fixed in -07
> >>
> >>         s1, para 2: s/under certain/beyond a certain/
> >>
> >>
> >>     [VPB] Fixed in -07
> >>
> >>
> >>         s1, para 3: s/makes a set of concrete implementation
> >>         recommendations/defines
> >>         two extensions/; s/- push higher/by increasing/; s/maintain
> >>         LSP state./maintain
> >>         LSP state by reducing the number of messages needed./
> >>
> >>         Abstract, para 2 and s1, last para:  [Omit reference from
> >>         Abstract]
> >>         OLD:
> >>            This document advocates the use of a couple of techniques -
> >>         "Refresh-
> >>            Interval Independent RSVP (RI-RSVP)" and "Per-Peer
> >>         Flow-Control" -
> >>            for significantly cutting down the amount of processing
> cycles
> >>            required to maintain LSP state.
> >>         NEW:
> >>            This document defines two RSVP Capabilities [RFC5063]
> "Refresh-
> >>            Interval Independent RSVP (RI-RSVP)" and "Per-Peer
> >>         Flow-Control"
> >>            that will cut down the number of messsages and processing
> >>         cycles
> >>            required to maintain LSP state.
> >>         ENDS
> >>
> >>
> >>     [VPB] Fixed in -07
> >>
> >>
> >>         s1, last para: Add new penultimate sentence:
> >>            Note that the "Per-Peer Flow-Control" capability requires
> >>         the "RI-RSVP"
> >>            capability as a prerequisite.
> >>
> >>
> >>     [VPB] Fixed in -07
> >>
> >>
> >>         s1, last para: s/RECOMMENDED/recommended/ - this isn't a
> >>         recommendation about
> >>         the protocol on the wire.
> >>
> >>
> >>     [VPB] Fixed in -07
> >>
> >>
> >>         Subdivision of s2:  The issues regarding the nature of the
> >>         document would be
> >>         helped by altering s2 into four top level sections, thus: s2:
> >>         Requirement for
> >>         RFC 2961 Refresh Overhead Reduction Support and Specific
> >>         Option Choices (from
> >>         s2.1) s3: Requirement for RFC 5063 Capability Object support
> >>         (see Minor Issues
> >>         above) s4: Refresh-Interval Independent RSVP Capability (from
> >>         s2.3) s5:
> >>         Per-Peer RSVP Flow Control Capability (from s2.4) Subsequent
> >>         major sections
> >>         then renumbered as s6 onwards. References to s2.x will need to
> >>         be updated
> >>         throughout.
> >>
> >>
> >>     [VPB] We subdivided s2 into 3 top level sections. We did not add a
> >>     separate section for discussing RFC5063 Capability Object support.
> >>
> >>
> >>         s2.1 (would be introduction of new s2):
> >>         OLD:
> >>            The implementation recommendations discussed in this
> >>         section are
> >>            based on the proposals made in [RFC2961] and act as
> >>         prerequisites for
> >>            implementing the techniques discussed in Sections 2.2 and
> 2.3.
> >>
> >>         NEW:
> >>            The Capabilities defined in Sections 4 and 5 of this
> >>         document are based on
> >>            proposals made in [RFC2961].  Implementations of these
> >>         Capabilities will
> >>            need to support the RSVP messages and techniques defined in
> >>         [RFC2961] as set
> >>            out in Section 2.1 [was 2.1.1] with
> >>            some minor modifications and alterations to recommended
> >>         time intervals and
> >>            iteration counts as defined in the remainder of this section.
> >>         ENDS
> >>
> >>
> >>     [VPB] Fixed in -07
> >>
> >>         s2.1.1, title and para 1 [will be s2.1]:
> >>         OLD:
> >>         2.1.1.  Basic Prerequisites
> >>
> >>            An implementation that supports the techniques discussed in
> >>         Sections
> >>            2.2 and 2.3 must meet certain basic prerequisites.
> >>         NEW:
> >>         2.1.  Required Functionality from RFC 2961 to be Implemented
> >>
> >>            An implementation that supports the capabiities discussed
> >>         in Sections
> >>            4 and 5 must provide a large subset of the functionality
> >>         described
> >>            in [RFC2961] as follows:
> >>         ENDS
> >>
> >>
> >>     [VPB] Fixed in -07
> >>
> >>
> >>         s2.1.2, para 2 [will be s2.2]: s/techniques discussed in
> >>         Sections 2.2 and
> >>         2.3/Capabilities defined in Sections 4 and 5/
> >>
> >>
> >>     [VPB] Fixed in -07
> >>
> >>
> >>         s2.1.2, para 2: s/MESSAGE ID/MESSAGE_ID/
> >>
> >>
> >>     [VPB] Fixed in -07
> >>
> >>
> >>         s2.2, para 1: s/improvement on transmission
> >>         overhead/improvement of
> >>         transmission overhead/
> >>
> >>
> >>     [VPB] Fixed in -07
> >>
> >>
> >>         s2.2, para 1: s/proposes sufficient recommendations/sets out
> >>         additional
> >>         requirements/
> >>
> >>
> >>     [VPB] Fixed in -07
> >>
> >>
> >>         s2.2, last bullet: Add a reference to the proposed new Section
> >>         3 that discusses
> >>         the Capability object.
> >>
> >>
> >>     [VPB] Added a direct reference to RFC5063
> >>
> >>
> >>         s2.2.1, last para: s/set Refresh-Reduction-Capable bit in
> >>         common header/set the
> >>         Refresh-Reduction-Capable bit in the common header/
> >>
> >>
> >>     [VPB] Fixed in -07
> >>
> >>
> >>         s2.3, para 1: s/set of recommendations/functionality/;
> >>         s/provide/provides/;
> >>         s/RSVP-TE control plane congestion/a significant portion of
> >>         the RSVP-TE control
> >>         message load/
> >>
> >>
> >>     [VPB] Fixed in -07
> >>
> >>
> >>         s2.3.2: s/MESSAGE ID/MESSAGE_ID/
> >>
> >>
> >>     [VPB] Fixed in -07
> >>
> >>
> >>
> >>         _______________________________________________
> >>         Teas mailing list
> >>         [e-mail] <mailto:[e-mail]>
> >>         https://www.ietf.org/mailman/listinfo/teas
> >>         <https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mailman_listinfo_teas&d=DwMDaQ&c=
> HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=
> CFHVfW0WsgxSqM6wTJiWE5evUJAdlUl1fm7E0WVbiS8&m=k7e-
> cloxf90XW9b_KRgpp7fxJRT4Q-f-_Nor0jTe8fg&s=g6wdiVKa0BcV5n4De8h3NjtO0hRGaF
> GruAncUJvpq_k&e=>
> >>
> >>
> >>
>
>