Subject: Genart last call review of draft-ietf-spring-segment-routing-ldp-interop-11

From: Joel Halpern <[email-masked]>
Date: Mon, 14 May 2018 13:01:10 -0700

Reviewer: Joel Halpern
Review result: Ready with Issues

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-spring-segment-routing-ldp-interop-11
Reviewer: Joel Halpern
Review Date: 2018-05-14
IETF LC End Date: 2018-05-24
IESG Telechat date: Not scheduled for a telechat

Summary: This document appears to be ready for publication as an RFC.  The
question of whether it is an Informational RFC or a Proposed Standards track
RFC is one that the ADs should examine.

Major issues:
    This document is quite readable, and quite useful.  If my reading below
    (minor comment about section 4.2) is wrong, then everything is fine. 
    However, reading the text, it does not appear to define SRMS.  Rather, it
    describes a good way to use SRMS to achive smooth SR - LDP integration and
    migration.  As such, this seems to me to be a really good Informational
    Document.

Minor issues:
    Section 4.2 states that it defines the SRMS (Segment Routing Mapping
    Server).  Looking at the relevant routing protocol document, they point to
    https://tools.ietf.org/html/draft-ietf-spring-conflict-resolution-05 as the
    defining source for the SRMS.  And that document does appear to define the
    SRMS.

Nits/editorial comments:

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Mon, 14 May 2018 20:12:11 +0000

Joel -

I am not an author of this draft - but I am an author on the referenced IS-IS draft - which I assume is one of the drafts mentioned in  your comment:

>     defining source for the SRMS.  

The IGP document references in the ldp-interop draft are stale. Newer versions of the IGP drafts have been published and they no longer reference draft-ietf-spring-conflict-resolution - a draft which is no longer active.

HTH

    Les

> -----Original Message-----
> From: spring <[email-masked]> On Behalf Of Joel Halpern
> Sent: Monday, May 14, 2018 1:01 PM
> To: [email-masked]
> Cc: [email-masked];
> [email-masked]; [email-masked]
> Subject: [spring] Genart last call review of draft-ietf-spring-segment-routing-
> ldp-interop-11
> 
> Reviewer: Joel Halpern
> I am the assigned Gen-ART reviewer for this draft. The General Area Review
> Team (Gen-ART) reviews all IETF documents being processed by the IESG for
> the IETF Chair.  Please treat these comments just like any other last call
> comments.
> 
> _______________________________________________
> spring mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spring

---

From: Joel Halpern Direct <[email-masked]>
Date: Mon, 14 May 2018 16:16:04 -0400

Thanks Les.  I wondered if that were the case.

Looking again at the draft, the problem then is that section 4.2 of the 
subject draft is not a normative definition of an SRMS.  It states the 
general functionality, and then provides an example of how it would work 
in the given scenario.

If the text were enhanced to be an effective normative definition of an 
SRMS, then that would also resolve the quesiton of the intended status 
of the draft.

Yours,
Joel

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Mon, 14 May 2018 20:32:03 +0000

Joel -

I don’t fully understand the rest of your comment then. You said:

" And that document does appear to define the  SRMS."

(where "that document" refers to draft-ietf-spring-conflict-resolution).

But the conflict resolution document never defined an SRMS - it merely described how SRMS advertisements were used in the context of conflict resolution.
So if you are unsatisfied with the "SRMS definition" in ldp-interop draft I think you need to be more clear as to what you think is lacking.

I leave it to the draft authors to resolve this issue with you.

    Les

> From: Joel Halpern Direct <[email-masked]>
> Sent: Monday, May 14, 2018 1:16 PM
> To: Les Ginsberg (ginsberg) <[email-masked]>; Joel Halpern
> <[email-masked]>; [email-masked]
> Subject: Re: [spring] Genart last call review of draft-ietf-spring-segment-
> routing-ldp-interop-11
> 
> Looking again at the draft, the problem then is that section 4.2 of the subject
> draft is not a normative definition of an SRMS.  It states the general
> functionality, and then provides an example of how it would work in the
> given scenario.
> 
> SRMS, then that would also resolve the quesiton of the intended status of
> the draft.
> 
> Yours,
> Joel
> 
> > I am not an author of this draft - but I am an author on the referenced IS-IS
> draft - which I assume is one of the drafts mentioned in  your comment:
> >
> > The IGP document references in the ldp-interop draft are stale. Newer
> versions of the IGP drafts have been published and they no longer reference
> draft-ietf-spring-conflict-resolution - a draft which is no longer active.
> >
> > HTH
> >
> >      Les
> >
> >
> >> Review Team (Gen-ART) reviews all IETF documents being processed by
> >> the IESG for the IETF Chair.  Please treat these comments just like
> >> any other last call comments.
> >>
> >> Summary: This document appears to be ready for publication as an RFC.
> >> The question of whether it is an Informational RFC or a Proposed
> >> Standards track RFC is one that the ADs should examine.
> >>
> >> Major issues:

---

From: Joel Halpern Direct <[email-masked]>
Date: Mon, 14 May 2018 16:33:30 -0400

I meant "this" (the document under review), not "that" 
(conflict-resolution).  Since the other documents I found indicated that 
conflict resolution defined it, I assumed it did.    Given that 
conflict-resolution is a dead document, something needs to actually 
define the SRMS.

Yours,
Joel

---

From: Ahmed Bashandy <[email-masked]>
Date: Mon, 21 May 2018 08:45:09 -0700

Thanks a lot for the review

The document specifies externally visible behavior that must be 
implemented by routers, otherwise SR and LDP routers cannot talk to each 
other. For example, section 4.2.2  specifies preference rules. Another 
example is the last two paragraphs in section 4.2.1. Hence I do not 
think it can be informational. A third example is section 4.2 which 
requires the existence of one SRMS in order for SR-only to speak to 
LDP-only routers

But I agree that a more crisp description of SRMS is warranted. I will 
add a section describing the SRMS functionality and specifying what to 
do when receiving both prefix-SID sub-tlv and SRMS advertisements in the 
next version, which I plan to send out in the next few days

Ahmed

---

From: Joel Halpern Direct <[email-masked]>
Date: Mon, 21 May 2018 12:13:12 -0400

Thank you.  I apologize for missing the other normative items.  With 
those, plus the elaboration on the SRMS, the status as PS makes good sense.

Yours,
Joel

On 5/21/18 11:45 AM, Ahmed Bashandy wrote:
>> The