My review comments [Re: MPLS-RT review of draft-kini-mpls-spring-entropy-label-01.txt]
Kamran Raza (skraza <skraza <at> cisco.com>
2014-10-17 02:41:52 GMT
I have reviewed the draft and here are my comments:
- I have found this document useful as it puts forward a good case of use
of EL in SR, as well as suggest EL procedures/algo for use in SR networks.
- I have found some sections (introductory + solution) that require some
cleanup / clarifications as per my per-section comments [ see below ].
- I believe that once author respin the rev that take care of
cleanup/re-org as per review comments, this document could be adopted as a
Following are my per-section detailed comments:
Section 1: Introduction:
Although reader could infer the problem statement by reading other text in
this section, IMO, this section needs to state the problem statement
explicitly and clearly. For example, the last para talks about ³A
recommended solution² without stating the problem explicitly.
In the Service chaining use case, it is easy to confuse as a reader/writer
amongst ³S² (the LSR) vs ³S1² (Svc) vs ³S2² (Svc). The example is further
complicated as you are using notion SN to denote where ³S² is used as node
Segment Id of LSR-N. All this makes the description of label stack
cluttered with too many Ss. I suggest using LSR I/E (or A/B) for src and
dest LSRs, N1/N2 instead of S1/S2 service LSRs, F1 and F2 for respective
service functions, and keep using SN for SID of node N. This means your
example of <SS1, S-SvcS1, SS2, S-SvcS2, SD> becomes <SN1, SF1, SN2, SF2,
- The title of this section is ³Recommended EL Solution for SPRING² ..
Should it not be renamed something like ³EL Procedures in SPRING² ?
- EL insertion algorithm needs to be bulletized or written in more
readable form (Flowchart?).
- As per my comment regarding section 4 title, the title needs renaming
from ³Options considered² to something like ³Discarded options for EL in
- I am not sure but should this section be moved to Appendix ?
- Or, should we not swap section 4 and 5 ? ‹ i.e. first list all the
options and why they were rejected, followed by the recommended one.
Section 8. Security considerations:
- The section is empty and needs some contents. At minimum, it needs to
state TBD to be addressed in later revisions.
On 2014-10-14, 4:11 PM, "Markus Jork" <mjork <at> juniper.net> wrote:
>I have been asked to review draft-kini-mpls-spring-entropy-label-01 as
>one of the MPLS-RT members.
>The document is coherent and makes a good argument for why the entropy
>label mechanism is useful and needed for SPRING. There are likely to be
>networks for which this would be beneficial.
>Unfortunately, the nature of the problem and existing hardware
>compatibility constraints don't lend themselves to very elegant
>solutions. The proposed solution in section 4 pretty much screams
>"compromise". But the following sections do a good job of describing the
>design constraints and why other solutions were rejected. It will be
>useful to keep this content in the document somewhere even in its final
>I believe the document is ready for WG adoption. Though I think there are
>a couple of small problems with the examples in section 5 that should be
>1. Up to section 5.1, the example label stack includes a label S-SvcS2
>for the service at S2. But in all the following sections, this label is
>dropped from the examples. I think it's best to leave this out in all of
>the examples for brevity.
>2. In section 5.3, the first example is given as <SS11, ELI, EL, S-SvcS1,
> That should be <SP1, ELI, EL, SS1, S-SvcS1, SS2, SD>
>3. In section 5.4, the example is given as:
> "For the same Figure 1 above, if LSR P1
> needs to have the EL within a depth of 4, then the source LSR S
> encoded label stack would be <SS1, S-SvcS1, ELI, EL2, SS2, SD> where
> all the ELs would typically have the same value."
>That is leaving out the first hop SP1 from the stack (which means the EL
>has to move up the stack). Also, only one EL is present. So why call it
mpls mailing list
mpls <at> ietf.org