Re: [Teas] Opsdir last call review of draft-ietf-teas-sr-rsvp-coexistence-rec-02

[Harish Sitaraman <[e-mail]>]

Hi Al,

We've posted a -03 version of the draft. Let us know if it helps with your comments based on the clarifications below.

Harish

On 4/16/18, 11:57 AM, "Harish Sitaraman" <[e-mail]> wrote:

    
    Hi Al,
    
    Thanks for the review comments. Comments are inline [HS]. Let me know if you've further questions. 
    
    ----
    On 4/12/18, 5:12 PM, "Al Morton" <[e-mail]> wrote:
    
        Reviewer: Al Morton
        Review result: Has Nits
        
            Recommendations for RSVP-TE and Segment Routing LSP co-existence
                     draft-ietf-teas-sr-rsvp-coexistence-rec-02.txt
        
        Overall:
        This memo considers coexistence of SR LSPs and RSVP-TE LSPs,
        or migration to SR, and lists 5 methods as solutions to the
        problems posed.  Although only one of the solutions (3.5) is
        developed in detail, the text never makes a clear recommendation
        among the 5 solutions. At least two seem viable (3.1 and 3.5).
        Operators would probably appreciate a clear recommendation from 
        the authors, if possible.
    
    [HS] 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.
        
        Edits/nits follow, see [acm]:
        
        
        1.  Introduction
        
           The problem space can be generalized as a dark bandwidth problem to
           cases where any other service exists in the network that runs in
           parallel across common links and whose bandwidth is not reflected in
           the available and reserved values in the TED.  The general problem is
           management of dark bandwidth pools and can be generalized to cases
           where any other service exists in the network that runs in parallel
           across common links and whose bandwidth is not reflected in the
           available and reserved values in the TED. 
        [acm]
        You've written two sentences above that essentially say the same thing.
        Although it appears in the Abstract, TED should be spelled-out in the 
        body text.
    
    [HS] Thanks for catching this. We can remove the 2nd sentence and TED can be again expanded in the Introduction.
        
           In most practical
           instances given the static nature of the traffic demands, limiting
           the available reservable bandwidth available to RSVP-TE has been an
           acceptable solution.  However, in the case of SR traffic, there is
           assumed to be very dynamic traffic demands and there is considerable
           risk associated with stranding capacity or overbooking service
           traffic resulting in traffic drops.
        
           The high level requirements or assumptions to consider are:
        
           1.  Placement of SR LSPs in the same domain as RSVP-TE LSPs MUST NOT
               introduce inaccuracies in the TED used by distributed or
               centralized path computation engines.
        
           2.  Engines that compute RSVP-TE paths MAY have no knowledge of the
               existence of the SR paths in the same domain.
        [acm] suggest 
        s/2.../Knowledge of the
               existence of the SR paths in the same domain is OPTIONAL for
        	   engines that compute RSVP-TE paths./
        or, s/MAY/may/ since this is only an assumption?
    
    [HS] We can s/MAY/may/ instead. The existing deployed path computation engines for RSVP-TE in the network may not know about the SR paths as they could be computed by another entity. As an assumption, this requirement is basically stating that solutions to co-exist RSVP-TE and SR should not assume or mandate that existing RSVP-TE path compute engines will know about the SR paths.
        
           3.  Engines that compute RSVP-TE paths SHOULD NOT require a software
               upgrade or change to their path computation logic.
        
           4.  Protocol extensions SHOULD be avoided or be minimal as in many
               cases this co-existence of RSVP-TE and SR MAY be needed only
               during a transition phase.
        
           5.  Placement of SR LSPs in the same domain as RSVP-TE LSPs that are
               computed in a distributed fashion MUST NOT require migration to a
               central controller architecture for the RSVP-TE LSPs.
        
        2.  Conventions used in this document
        
           The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
           "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
           document are to be interpreted as described in RFC 2119 [RFC2119].
        
        3.  Solution options
        
        3.1.  Static partitioning of bandwidth
        
           In this model, the static reservable bandwidth of an interface can be
           statically partitioned between SR and RSVP-TE and each can operate
           within that bandwidth allocation and SHOULD NOT preempt each other.
        
           While it is possible to configure RSVP-TE to only reserve up to a
           certain maximum link bandwidth and manage the remaining link
           bandwidth for other services, this is a deployment where SR and RSVP-
           TE are separated in the same network (ships in the night) and can
           lead to suboptimal link bandwidth utilization not allowing each to
           consume more, if required and constraining the respective
           deployments.
        
           The downside of this approach is the inability to use the reservable
           bandwidth effectively and inability to use bandwidth left unused by
           the other protocol.
        [acm] 
        ... so this option satisfies all requirements and assumptions?
    
    [HS] Correct. The document points out specific requirements that are not satisfied under such solutions.
        
        3.2.  Centralized management of available capacity
        
           In this model, a central controller performs path placement for both
           RSVP-TE and SR LSPs.  The controller manages and updates its own view
           of the in-use and the available capacity.  As the controller is a
           single common entity managing the network it can have a unified and
           consistent view of the available capacity at all times.
        [acm]
        Comment and a question:
        This also makes the central controller a single point of failure.
        What is the Recovery & Restoration Strategy? (care to cite a reference?)
    
    [HS] It is not necessarily a single point of failure as it depends on the deployment model of the controller in the network. The wording “single common entity” generically refers to a centralized controller managing path computation for all RSVP-TE and SR paths in the network. Recovery and restoration of the controller seems orthogonal to how the operator chooses to deploy 3.2.
        
           A practical drawback of this model is that it requires the
           introduction of a central controller managing the RSVP-TE LSPs as a
           prerequisite to the deployment of any SR LSPs.  Therefore, this
           approach is not practical for networks where distributed TE with
           RSVP-TE LSPs is already deployed, as it requires a redesign of the
           network and is not backwards compatible.  This does not satisfy
           requirement 5.
        
           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.
        [acm] 
        ... So, this option fails to satisfy key requirements and assumptions.
        (suggest to state that)
    
    [HS] Correct. The above text states that 5 and 2 are not satisfied.
        
        ...
        
        3.5.  TED consistency by reflecting SR traffic
        
        ...
        
           The following methodology can be used at every TE node for this
           solution:
        [acm]
        sugest to identify this list as Parameters for the methodology.
        s/solution:/solution, using the following parameters:/
        
    [HS] Ok. New text: “The following methodology can be used at every TE node for this solution, using the following parameters:”
        
           o  T: Traffic statistics collection time interval
        
           o  N: Traffic averaging calculation (adjustment) interval such that N
              = k * T, where k is a constant integer multiplier greater or equal
              to 1.  Its purpose is to provide a smoothing function to the
              statistics collection.
        [acm]
        k should be a separate list item, preceding N.
    
    [HS] Ok. The new text is
    
      o k: The number of traffic statistics samples that can provide a smoothing function 
         to the statistics collection. The value of k is a constant integer multiplier greater or equal
         to 1.  
      o  N: Traffic averaging calculation (adjustment) interval such that N = k * T.
    
    --
    Harish