Re: [spring] AD Review of draft-ietf-spring-segment-routing-msdc-05

Hi Alvaro,

Please observe that in overlay networking it is reall hosts how can compute
required path or exit gateway and apply it to packets. Think about Contrail
or Nuage.

It is also not about "programming hosts to apply a header" it is hosts
itself determine based on the local application needs what the header is.
This is naturally applicable to msdc.

The times where the network nodes only do networking are long time gone.

Best,
R.

On Aug 31, 2017 22:40, "Alvaro Retana (aretana)" <aretana@cisco.com> wrote:

Dear authors:

I just finished reading this document.  Thanks for a clear and straight
forward draft!

I have some comments (see below).  The main one is about the inclusion of
hosts as defining the source routed path, without them being explicitly
called out in the draft-ietf-spring-segment-routing.  Knowing that some of
the authors overlap, please make sure there are no holes in the
Architecture.  I will start the IETF LC once this item is addressed, and a
revised ID is produced do address the other comments, as needed.

Thanks!

Alvaro.

Major:

M1. As with draft-ietf-spring-segment-routing-central-epe, it worries me
that hosts are called out as being able to define the source routed path.
Please make sure that the Architecture document has some text about the use
of hosts – maybe constrained to the case where the hosts can be
programmed.  Section 6 provides some good text for that.

Minor:

P1. “service chain”: please remove to avoid confusion with SFC (same
comment as for all the SR documents).

P2. References:

- s/rfc3107/draft-ietf-mpls-rfc3107bis

- The references to I-D.ietf-spring-segment-routing-central-epe and rfc7938
should be Normative.

P3. There are 2 instances of using rfc2119 language, I don’t think that
either is needed because you’re really paraphrasing other documents.  IOW,
I recommend you take the Normative language off.

P3.1. Section 4.2.1. (Control Plane): “The implicit-null label in the NLRI
tells Node10 that it is the penultimate hop and MUST pop the top label…”
This is normal MPLS operation, so the MUST is really not introducing
anything new, just paraphrasing the MPLS architecture.  Instead of the
MUST, a reference to MPLS would be more than enough.  s/MUST/must

P3.2. Section 11. (Manageability Considerations): “As recommended in
[I-D.ietf-spring-segment-routing], the same SRGB SHOULD be allocated in all
nodes…”   The Architecture document doesn’t (yet) make that recommendation
explicitly, but a pointer to it should be enough.  s/SHOULD/should

P4. Section 4.2.4. (Global BGP Prefix Segment through the fabric): “…a
packet with top label 16011 received by any node in the fabric…and the
label 16011 is penultimate-popped at Node10”, or at Node9, right?

P5. Section 4.3: “…and with the BGP-Prefix-SID attribute extension defined
in this document”; that was not defined in this document.

P6. Section 4.3. (iBGP Labeled Unicast (RFC3107)) contains this text: “AIGP
metric ([RFC7311]) is likely applied to the BGP-Prefix-SID as part of a
large-scale multi-domain design such as Seamless MPLS
[I-D.ietf-mpls-seamless-mpls].“  This paragraph sounds random to me as
there is no further explanation of the use, impact, advantages, etc.
Neither AIGP/Seamless MPLS is mentioned again in the document, nor in
draft-ietf-idr-bgp-prefix-sid or rfc7938.  Please either expand the
concepts/use or delete this paragraph.

P7. Section 5. (Applying Segment Routing in the DC with IPv6 dataplane):
“Node5 originates 2001:DB8::5/128 with the attached BGP-Prefix-SID
advertising the support of the Segment Routing extension header (SRH,
[I-D.ietf-6man-segment-routing-header])…”   draft-ietf-idr-bgp-prefix-sid
says nothing explicitly about the BGP-Prefix-SID Attribute advertising
support for the SRH – maybe it should, but it doesn’t.

NEW>

   Node5 originates 2001:DB8::5/128 with the attached BGP-Prefix-SID

  for IPv6 packets destined to

   segment 2001:DB8::5 ([I-D.ietf-idr-bgp-prefix-sid]).

Instead, put the reference later in the same section where it says
“…sending IPv6 packets with a SRH extension header…”.

Nits:

N1. s/BGP4/BGP-4

N2. Section 3: “Further in this document…”  A reference to Section 7 would
be nice.

N3. s/index11)/index11

N4. It would have been nice to illustrate the operation in 4.2.x using IPv6
addresses.

N5. Throughout most of the document the nodes are referred to as Nodex, but
there are a couple of places where Torx is used.  Even though these nodes
have been identified as ToRs, it would be nice to be consistent to avoid
confusion.

N6. Section 7: s/problems describe above/problems described above   Also,
putting a reference back to Section 3 would be nice.

N7. The content in Section 7 is good, and the DC example helps in the
illustration – but the applicability is not just constrained to it.  It
might be a good idea to add at note at the start mentioning the broader
applicability.

N8. Please avoid using “we”.

_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring