Re: [mpls] Spencer Dawkins' Discuss on draft-ietf-mpls-tp-shared-ring-protection-05: (with DISCUSS and COMMENT)

[Spencer Dawkins at IETF <[e-mail]>]

Hi, Huub,

On Fri, Jun 2, 2017 at 5:29 PM, Huub van Helvoort <[e-mail]>
wrote:

> Hello Spencer,
>
> I am back from our holiday.
> As promised I will now answer the remaining comments
> in-line [Huub]
>

Thanks - and all your proposed responses in this e-mail seem good to me.

Spencer


>
> ----------------------------------------------------------------------
>> DISCUSS:
>> ----------------------------------------------------------------------
>>
> ---8<--- snipped (see my previous response)
>
>> ----------------------------------------------------------------------
>> COMMENT:
>> ----------------------------------------------------------------------
>>
>> ---------- all the other questions
>>
>> In this text,
>>
>>     When the service LSP passes through the interconnected rings, the
>>     direction of the working ring tunnels used on both rings SHOULD be
>>     the same.  For example, if the service LSP uses the clockwise
>> working
>>     ring tunnel on Ring1, when the service LSP leaves Ring1 and enters
>>     Ring2, the working ring tunnel used on Ring2 SHOULD also follow the
>>     clockwise direction.
>>
>> I'm not understanding why this is a SHOULD, and not a MUST. If the
>> direction of the working ring tunnels used on both rings is not the same,
>> does this still work?
>>
>
> [Huub] it will still work.
> The SHOULD is in particular useful in case of  dual-node interconnected
> rings. It ensures that the traffic passes only one of the two
> interconnecting
> nodes, and does not pass the link between the two interconnecting nodes.
> The traffic will then only be switched to the protection path if the
> interconnecting node fails which is in working path.
>
> If it still works, why does this matter? But, either way, you might
>> usefully say something about why this isn't always the right thing to do,
>> even if you just give one example. The point of SHOULD is that
>> implementers make their own informed decisions, so providing information
>> that will inform those decisions seems important.
>>
>
> [Huub] OK, point taken.
>
> I wanted to call out
>>
>>     Ring switches MUST be preempted by higher priority RPS requests.
>> For
>>     example, consider a protection switch that is active due to a manual
>>     switch request on the given link, and another protection switch is
>>     required due to a failure on another link.  Then an RPS request MUST
>>     be generated, the former protection switch MUST be dropped, and the
>>     latter protection switch established.
>>
>>     MSRP mechanism SHOULD support multiple protection switches in the
>>     ring, resulting in the ring being segmented into two or more
>> separate
>>     segments.  This may happen when several RPS requests of the same
>>     priority exist in the ring due to multiple failures or external
>>     switch commands.
>>
>> as really good examples of the kind of text I think would help the places
>> in this document ("For example", "This may happen when") where no
>> examples are given. Thanks for providing those examples!
>>
>
> [Huub] thank you for your advise.
>
> Ouch. Do I understand from
>>
>>     o  Protection Switching Mode (M): This 2-bit field indicates the
>>        protection switching mode used by the sending node of the RPS
>>        message.  This can be used to check that the ring nodes on the
>>        same ring use the same protection switching mechanism.  The
>>        defined values of the M field are listed as below:
>>
>>               +------------------+-----------------------------+
>>               |  Bits (MSB-LSB)  |   Protecton Switching Mode  |
>>               +------------------+-----------------------------+
>>               |       0 0        |         Reserved            |
>>               |       0 1        |         Wrapping            |
>>               |       1 0        |       Short Wrapping        |
>>               |       1 1        |         Steering            |
>>               +------------------+-----------------------------+
>>
>> that you already have three protection mechanisms, and have only one
>> possible codepoint to allocate for any future optimizations? Assuming
>> that "0 0" can be unReserved ...
>>
>
> [Huub] I hope the explanations I provided for the application of
> wrapping/short-wrapping/steering show that these are the only
> three possible mechanisms.
>
> Could you clarify what "anyway" means in this text?
>>
>>     When multiple MS RPS requests exist at the same time addressing
>>     different links and there is no higher priority request on the ring,
>>     no switch SHOULD be executed and existing switches MUST be dropped.
>>     The nodes MUST signal, anyway, the MS RPS request code.
>>
>
> [Huub] good point. To avoid confusion it would be better to
> replace the last sentence by:
> "The node still SHOULD signal the relevant RPS request".
>
> I'm seeing that the commands like LP described in section 5.2.1.1  are
>> used in the document before these (I'm serious) helpful and clear
>> explanations appear. If it's possible to move section 5.2.1.1 up in the
>> document, that would be great, but if it isn't possible, a forward
>> pointer would be helpful to readers who don't already know what the
>> command abbreviations mean.
>>
>
> [Huub] good point, we will take this into account when we make
> the revision of the draft.
>
> I'm really confused by this SHOULD:
>>
>>     The PSC protocol [RFC6378] is designed for point-to-point LSPs, on
>>     which the protection switching can only be performed on one or both
>>     of the end points of the LSP.  The RPS protocol is designed for ring
>>     tunnels, which consist of multiple ring nodes, and the failure could
>>     happen on any segment of the ring, thus RPS SHOULD be capable of
>>     identifying and handling the different failures on the ring, and
>>     coordinating the protection switching behavior of all the nodes on
>>     the ring.
>>
>> I suspect that's because it's not a 2119 SHOULD, but if people think it
>> is, I wouldn't mind understanding why.
>>
>
> [Huub] you are right that is not a 2119 SHOULD,
> It would be better to replace "SHOULD be" by "is".
> (the protocol has been implemented and the capability has been tested
> successfully)
>
> Section 5.3, "RPS and PSC Comparison on Ring Topology" is really helpful,
>> but it appears 43 pages in. Given that I'd expect people to be asking why
>> they should implement a new protection switching protocol when they've
>> already implemented PSC, I'd think this would be much more useful, early
>> in the document.
>>
>
> [Huub] we can move the text up in the draft.
>
> I'm somewhat confused about the code point allocation strategy in this
>> text:
>>
>>     The RPS Request Field is 8 bits, the allocated values are as
>> follows:
>>
>>         Value       Description               Reference
>>        -------  --------------------------- ---------------
>>           0     No Request (NR)             this document
>>           1     Reverse Request (RR)        this document
>>           2     unassigned
>>           3     Exercise (EXER)             this document
>>           4     unassigned
>>           5     Wait-To-Restore (WTR)       this document
>>           6     Manual Switch (MS)          this document
>>          7-10   unassigned
>>          11     Signal Fail (SF)            this document
>>          12     unassigned
>>          13     Forced Switch (FS)          this document
>>          14     unassigned
>>          15     Lockout of Protection (LP)  this document
>>        16-254   unassigned
>>          255    Reserved
>>
>> My first question is, why the highest priority RPS value is 15, given
>> that the field is 8 bits wide.
>>
>
> [Huub] the four LSB of the request field are sufficient for the
> required values. (in PSC and other technologies also four bits
> are used for the request coding).
>
> If anyone ever needs to add a code point
>> higher than the highest priority code point, will that work well?
>>
>
> [Huub] that will never be necessary. LP means protection is disabled.
>
>   I can
>> imagine code that says "if operation_priority is greater than
>> highest_priority, it's an error", for example.
>>
>
> [Huub] indeed, this will be reported as FOP (failure of protocol).
>
> Best regards, Huub.
>
>
>
> --
> ================================================================
> Always remember that you are unique...just like everyone else...
>
>