Re: [spring] Adam Roach's No Objection on draft-ietf-spring-segment-routing-13: (with COMMENT)

[Benoit Claise <[e-mail]>]

On 12/13/2017 6:58 PM, Adam Roach wrote:
> Adam Roach has entered the following ballot position for
> draft-ietf-spring-segment-routing-13: 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://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> Thanks to everyone who put in work on this document. I do note that the list of
> authors is over the five-author recommended limit. I checked both the ballot
> and the shepherd write-up, and was a little surprised not to find an
> explanation of why this document is exceptional in this regard.
>
> I have one major comment and a handful of editorial comments.
>
> The major comment regards the treatment of trust assumptions in the security
> section. The SR-MPLS section asserts: "[T]here is an assumed trust model such
> that any node imposing a label stack on a packet is assumed to be allowed to do
> so"; the SRv6 section has a similar assertion: "[T]here is an assumed trust
> model such that any node adding an SRH to the packet is assumed to be allowed
> to do so."
>
> I leave it to the security area directors to speak to whether it is okay in
> 2017 to publish documents that forego integrity protection of source routing
> information based on assumptions of perfectly secured networks. Irrespective of
> the answer to that question, I'm perplexed that the security section does not
> go into detail about the consequences that arise when these assumptions are
> violated. I think a clear description of these consequences is relevant and
> necessary to include, as it informs the level of care that is appropriate for
> both implementation and deployment of these protocols.
>
> I want to be clear that I consider this a major flaw in the document, and am on
> the fence regarding whether it should constitute a blocking DISCUSS. I would
> support anyone else in issuing a DISCUSS on this topic.
>
> Editorial comments follow.
>
> Section 2 contains the following text:
>
>     Active Segment: the segment that MUST be used by the receiving router
>     to process the packet.
>
> I really don't think you want to use normative language in the terminology
> section. I strongly recommend moving this requirement down to a section that
> bears more directly on implementation.
Btw, there are more occurrences than this one.

    SR Local Block (SRLB): local property of an SR node.  If a node
    participates in multiple SR domains, there is one SRLB for each SR
    domain.  In SR-MPLS, SRLB is a set of local labels reserved for local
    segments.  In SRv6, SRLB is a set of local IPv6 addresses reserved
    for local SRv6 SID's.  In a controller-driven network, some
    controllers or applications MAY use the control plane to discover the
    available set of local segments.


Regards, Benoit
>
> Section 3.4.2:
>
>     These extensions are defined in IGP SR extensions documents.
>
> Please add a citation to the relevant documents.
>
> Section 3.5:
>
>     ABRs G and J will propagate the prefix and its SIDs into the backbone
>     area by creating a new instance of the prefix according to normal
>     inter-area/level IGP propagation rules.
>
> Please expand the term "ABR" on first use.
>
>
> .
>