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

[Huub van Helvoort <[e-mail]>]

Hello Spencer,

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

> ----------------------------------------------------------------------
> 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...