Re: [Teas] Alvaro Retana's No Objection on draft-ietf-teas-sr-rsvp-coexistence-rec-03: (with COMMENT)

[Harish Sitaraman <[e-mail]>]

Hi Alvaro,

Thanks for your review comments. Please see inline [HS]...

On 5/8/18, 5:47 AM, "Alvaro Retana" <[e-mail]> wrote:

    Alvaro Retana has entered the following ballot position for
    draft-ietf-teas-sr-rsvp-coexistence-rec-03: 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://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_iesg_statement_discuss-2Dcriteria.html&d=DwIDaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=CXKOXD_3UIPrRhmyXS8lTOnJ2ZY8S-bng806Yu9IBa0&m=TLOz2gHnca7-96T3D19D0PaKwAjLfXD-9Omd2gL5Xig&s=F5hyR8TprarYNOOmisrr3vphde9_VoIu_k2gndnt27E&e=
    for more information about IESG DISCUSS and COMMENT positions.
    
    
    The document, along with other ballot positions, can be found here:
    https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dteas-2Dsr-2Drsvp-2Dcoexistence-2Drec_&d=DwIDaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=CXKOXD_3UIPrRhmyXS8lTOnJ2ZY8S-bng806Yu9IBa0&m=TLOz2gHnca7-96T3D19D0PaKwAjLfXD-9Omd2gL5Xig&s=A3WH8hRvuZ8tnerORf6Nf31nkO-7Y22n8JXq1n3uihE&e=
    
    
    
    ----------------------------------------------------------------------
    COMMENT:
    ----------------------------------------------------------------------
    
    (1) The Abstract says that this document provides "solution options" -- it
    would be very nice if a recommendation (or at least general guidance) was
    provided by the authors.  This point was brought up in the OpsDir review [1],
    to which the authors replied:
    
       "The intent behind the recommendations is to not take a position on which
       solution is preferable. All solutions are valid but some do not satisfy all
       the requirements. However, if a solution is acceptable (based on their
       deployment of SR and RSVP and knowing which requirements are not satisfied)
       for an operator then such a solution can be chosen. "
    
    That seems like a reasonable answer.  It would be good if, at least, text to
    the effect was included in the document.

[HS] Ok. We can add the following text in section 3 (before 3.1):
[HS]
The following section lists SR and RSVP co-existence solution options. A specific solution is not recommended as
all solutions are valid even though some may not satisfy all the requirements. If a solution is
acceptable for an operator based on their deployment model then such a solution can be chosen.
    
    (2) Given, from the text above, that not all requirements may be as important
    in a specific deployment, I find the use of rfc2119 language to describe them
    (in the Introduction) confusing and inappropriate.  Please consider not using
    Normative text in that section.

[HS] I'm ok to lower case the normative words in all requirements considering an operator can still choose a solution knowing that it provides.
    
    (3) While wondering whether there was a recommendation coming out of this
    document, I looked for other documents referencing it, and found 1:
    draft-ietf-mpls-rsvp-shared-labels ("Signaling RSVP-TE tunnels on a shared MPLS
    forwarding plane").  I realize that the topic is not exactly a match, but this
    sentence is included in it: "The RSVP-TE tunnels that use this shared
    forwarding plane can co-exist with MPLS-SR LSPs
    [I-D.ietf-spring-segment-routing-mpls] as described in
    [I-D.ietf-teas-sr-rsvp-coexistence-rec]."
    
    I took a very quick look at draft-ietf-mpls-rsvp-shared-labels and the
    mechanism described there didn't look like any of the options described here. 
    Is the mechanism described in draft-ietf-mpls-rsvp-shared-labels an option to
    the problem addressed in this document?  If so, is it worth including a short
    description?  If not, then the sentence above sounds misleading.
    
    [I realize I may be asking questions about a different document...but I'm
    taking the license given that the editor for this document is also an author in
    the other one. ;-) ]

[HS] The point in the shared-labels draft is that if there was a network running that new SR RSVP-TE tunnel and 
if that network needs to introduce SR then any of the solutions in the co-existence draft can still be used. In any case, 
no change is required in the co-existence draft and we can revisit the text in the shared-labels draft later, if necessary.
   
    (4) Nits:
    
    (4.1) This text in the Abstract seems redundant: "In some instances, operators
    are also migrating existing services from RSVP-TE to SR LSPs...In other cases,
    services running on RSVP-TE might be migrated to run over SR."

[HS] We can remove the line "In other cases, services running on RSVP-TE might be migrated to run over SR."
    
    (4.2) From §3.2:
       Note that it is not enough for the controller to just maintain the
       unified view of the available capacity, it must also perform the path
       computation for the RSVP-TE LSPs, as the reservations for the SR LSPs
       are not reflected in the TED.  This does not fit with assumption 2
       mentioned earlier.
    
    Assumption 2 says that "Engines that compute RSVP-TE paths may have no
    knowledge of the existence of the SR paths in the same domain.", but in the
    scenario described here (where the controller "must also perform the path
    computation for the RSVP-TE LSPs"), then the assumption is not true as the
    controller would in fact have knowledge of the coexistence.  This is just a
    nit: I don't think the last sentence is accurate...

[HS] We can remove the last sentence "This does not fit with assumption 2 mentioned earlier."
The intent with the requirement was that RSVP-TE compute engines may be distributed but in this
case both are centralized.
    
    (4.3) This text is normatively redundant: "It is RECOMMENDED that the IGP-TE
    update threshold SHOULD be lower..."  RECOMMENDED and SHOULD mean the same
    thing.

[HS] We can change this to "The IGP-TE update threshold SHOULD be lower..."

--
Harish