Re: [spring] AD Review of draft-ietf-spring-segment-routing-central-epe-06

[Alvaro Retana <[e-mail]>]

On October 30, 2017 at 1:53:07 AM, Gaurav Dawra (gdawra) ([e-mail])
wrote:

Gaurav:

Hi!  Thanks for taking over this document!

I have some remaining comments below, please take a look.  I’m starting the
IETF Last Call, which will be extended to account for the IETF meeting and
the US Holidays.

Thanks!

Alvaro.


...

M2.3. “The solution SHOULD minimize the need for new BGP capabilities at
the ingress PEs.”  What is the explicit requirement, that needs the
“SHOULD”, from an interoperability point of view?

<Gaurav> At Ingress PE, this requirement covers that there is need for some
minimal configuration or protocol extension for Egress Engineering.

Ok, but (1) the text doesn’t talk about configuration (just capabilities),
and (2) I really think that Normative Language should not be used in this
case because there’s really nothing that can be enforced: “SHOULD” means
that “there may exist valid reasons in particular circumstances to ignore a
particular item”, so there’s nothing that can be done if an extension or
configuration is justified.  Please s/SHOULD/should.


M2.4. “The solution MUST accommodate an ingress BGP-EPE policy at an
ingress PE or directly at a source host within the domain.”  “MUST
accommodate”??  What are you looking for?  The ability to program at those
points?  The ability to instantiate any policy?

<Gaurav> Solution MUST cover the ability to accommodate instantiation and
programming of the BGP-EPE policy at Ingress.

How about this:

New>

The solution MUST support the definition of an ingress BGP-EPE policy at
either the ingress PE or at the source of the traffic.

(I took “host” out because I assume that a PE in the other network is also
a valid place.)

...

P2. The examples in Sections 3.x seem incomplete and inaccurate to me.
Also, the names used don’t match what is specified in
draft-ietf-idr-bgpls-segment-routing-epe.  In general, please be consistent
with the names!  For example:



Section 3.1. (PeerNode SID to D):

“

   Descriptors:



   o  Node Descriptors (BGP router-ID, ASN): 192.0.2.3, AS1



   o  Peer Descriptors (peer BGP router-ID, peer ASN): 192.0.2.4, AS2



   o  Link Descriptors (IP interface address, neighbor IP address):

      2001:db8:cd::c, 2001:db8:cd::d



   Attributes:



   o  PeerNode SID: 1012

“



Comments>

- Section 5.1 in draft-ietf-idr-bgpls-segment-routing-epe uses “Local Node
Descriptor” instead of simply “Node Descriptor”, and the BGP-LS ID is
missing above.

- s/Peer Descriptors/Remote Node Descriptor

- The Link Descriptor uses the terms “IPv6 Interface Address” and “IPv6
Neighbor Address”…

- s/Attributes/Link Attribute

 <Gaurav> ACK> Will compare and address in next update.

3.2-3.5 were not updated with the IPv6 names.


...

P4. References:

- Please add a reference for BMP and IPFIX.

- Put the reference to BGP-LS on first mention (and not just way down in
Section 9).

- Replace the reference to RFC3107 with draft-ietf-mpls-rfc3107bis – and it
can be made Informative.

Not all the references were updated, and rfc3107bis is now rfc8277 anyway.