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

From: "Gaurav Dawra (gdawra)" <[email-masked]>
Date: Tue, 19 Dec 2017 07:01:12 +0000

Hey Alvaro,

Thanks a lot again for your review. Have posted the next version. Please see response inline <Gaurav_1>.

Regards,

Gaurav

From: Alvaro Retana <[email-masked]>
Date: Friday, November 3, 2017 at 7:33 AM
To: Gaurav Dawra <[email-masked]>, "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, Bruno Decraene <[email-masked]>
Subject: Re: [spring] AD Review of draft-ietf-spring-segment-routing-central-epe-06

On October 30, 2017 at 1:53:07 AM, Gaurav Dawra (gdawra) ([email-masked]<mailto:[email-masked]>) 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.

<Gaurav_1> ACK Updated. Addressed in next version.

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.)
<Gaurav_1> ACK Updated. Addressed in next version.

...

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.

<Gaurav_1> ACK Updated. Addressed in next version.

...
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.

<Gaurav_1> ACK Updated. Addressed in next version.

---

From: <[email-masked]>
Date: Thu, 21 Dec 2017 11:06:19 +0000

Hi Gaurav,

Many thanks for the updated draft.
As the document shepherd, please find below a follow up on Alvaro’s comment, prefixed with [Bruno]

From: Gaurav Dawra (gdawra) [mailto:[email-masked]]
Sent: Tuesday, December 19, 2017 8:01 AM
To: Alvaro Retana; [email-masked]
Cc: [email-masked]; [email-masked]; DECRAENE Bruno IMT/OLN; Gaurav Dawra (gdawra)
Subject: Re: [spring] AD Review of draft-ietf-spring-segment-routing-central-epe-06

Hey Alvaro,

Regards,

Gaurav

From: Alvaro Retana <[email-masked]<mailto:[email-masked]>>
Date: Friday, November 3, 2017 at 7:33 AM
To: Gaurav Dawra <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Bruno Decraene <[email-masked]<mailto:[email-masked]>>
Subject: Re: [spring] AD Review of draft-ietf-spring-segment-routing-central-epe-06

Gaurav:

Thanks!

Alvaro.

...

[…]
P4. References:

[Bruno] Reading -08, I’m still seeing references to RFC 3107, including in the table of content.

I’d propose to reuse the terminology from https://tools.ietf.org/html/draft-ietf-spring-segment-routing-msdc-07 which uses “BGP Labeled Unicast (RFC8277)”.

More specifically, I’d propose the following change

OLD: 5.3.  At a Router - RFC3107 policy route

NEW: 5.3.  At a Router – BGP Labeled Unicast route (RFC8277)

OLD: The BGP-EPE Controller could build a RFC3107<https://tools.ietf.org/html/rfc3107> ([RFC8277<https://tools.ietf.org/html/rfc8277>]) route

NEW: The BGP-EPE Controller could build a BGP Labeled Unicast route ([RFC8277<https://tools.ietf.org/html/rfc8277>])

OLD: This RFC3107<https://tools.ietf.org/html/rfc3107> policy route

NEW: This BGP Labeled unicast route (RFC8277)<https://tools.ietf.org/html/rfc3107>

I’m afraid that I also have a technical comment on this part. Draft says:

“o  Some BGP policy to ensure it will be selected as best by the ingress router.

   This RFC3107<https://tools.ietf.org/html/rfc3107> policy route "overwrites" an equivalent or less-specific "best path".»

As I reader, I would understand the first sentence as increasing the preference of the labeled Unicast route, e.g. using LOCAL_PREF or some local weight.

However, the problem is more complex as (unfortunately IMHO) the IETF did not specify the behavior when a BGP speaker receive both a labeled (SAFI 4) and unlabeled (SAFI 1) BGP route for the same IP prefix. As a result, the behavior is implementation dependent and non-interoperable, as discussed in https://tools.ietf.org/html/rfc8277#section-5. For example, some implementations consider both routes as non-comparable, in which case, increasing the preference of a route will not make it best/selected.

I don’t think that’s a big problem for the draft, but I think the point should be raised for the reader, when considering the different options presented in section 5 “Programming an input policy”.

I would suggest the following small change, but please feel free to adapt the text as you wish:

OLD: Some BGP policy to ensure it will be selected as best by the ingress router.

NEW: Some BGP policy to ensure it will be selected as best by the ingress router. Note that as discussed in RFC 8277 section 5, the comparison of labeled and unlabeled unicast BGP route is implementation dependent and hence may require an implementation specific policy on each ingress router.

Thanks,

Regards,

--Bruno

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: "Gaurav Dawra (gdawra)" <[email-masked]>
Date: Thu, 21 Dec 2017 14:13:25 +0000

Hey Bruno,

Thanks for the review. Please see inline [Gaurav_2]

Regards,

Gaurav

From: Bruno Decraene <[email-masked]>
Date: Thursday, December 21, 2017 at 3:06 AM
To: Gaurav Dawra <[email-masked]>, Alvaro Retana <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: [spring] AD Review of draft-ietf-spring-segment-routing-central-epe-06

Hi Gaurav,

Hey Alvaro,

Regards,

Gaurav

Gaurav:

Thanks!

Alvaro.

...

[…]
P4. References:

<Gaurav_2> ACK. Thanks for capturing these. Updated in next rev.

<Gaurav_2> ACK, Absolutely! This has been fixed in next rev as well.

Cheers,

Gaurav

Thanks,

Regards,

--Bruno

Thank you.

---

From: <[email-masked]>
Date: Thu, 21 Dec 2017 14:22:01 +0000

Thanks Gaurav, for the quick answer and for fixing the draft.

Regards,
--Bruno

From: Gaurav Dawra (gdawra) [mailto:[email-masked]]
Sent: Thursday, December 21, 2017 3:13 PM
To: DECRAENE Bruno IMT/OLN; Alvaro Retana
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [spring] AD Review of draft-ietf-spring-segment-routing-central-epe-06

Hey Bruno,

Regards,

Gaurav

From: Bruno Decraene <[email-masked]<mailto:[email-masked]>>
Date: Thursday, December 21, 2017 at 3:06 AM
To: Gaurav Dawra <[email-masked]<mailto:[email-masked]>>, Alvaro Retana <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [spring] AD Review of draft-ietf-spring-segment-routing-central-epe-06

Hi Gaurav,

From: Gaurav Dawra (gdawra) [mailto:[email-masked]]
Sent: Tuesday, December 19, 2017 8:01 AM
To: Alvaro Retana; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; DECRAENE Bruno IMT/OLN; Gaurav Dawra (gdawra)
Subject: Re: [spring] AD Review of draft-ietf-spring-segment-routing-central-epe-06

Hey Alvaro,

Regards,

Gaurav

Gaurav:

Thanks!

Alvaro.

...

[…]
P4. References:

Cheers,

Gaurav

Thanks,

Regards,

--Bruno

Thank you.

---

From: <[email-masked]>
Date: Thu, 21 Dec 2017 14:39:48 +0000

I see that you have also added the “note” on for the VPN routes. I don’t think it’s necessary here as:
- if both routes are VPN ones, they are both labelled and are comparable as per regular BGP/MPLS IP VPN routes
- if only the “policy” route is installed in the VRF (VRF fallback to the main FIB), only the labeled VPN routes is considered, hence preferred.

Bottom line, I think that the note can be removed in the VPN section (5.4). But nothing urgent, this can wait for a next update.

Thanks,
Regards,
--Bruno

From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, December 21, 2017 3:22 PM
To: Gaurav Dawra (gdawra)
Cc: [email-masked]; [email-masked]; [email-masked]; Alvaro Retana
Subject: RE: [spring] AD Review of draft-ietf-spring-segment-routing-central-epe-06

Regards,
--Bruno

Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

Hey Bruno,

Regards,

Gaurav

Hi Gaurav,

Hey Alvaro,

Regards,

Gaurav

Gaurav:

Thanks!

Alvaro.

...

[…]
P4. References:

Cheers,

Gaurav

Thanks,

Regards,

--Bruno

Thank you.

Thank you.

---

From: Alvaro Retana <[email-masked]>
Date: Thu, 21 Dec 2017 10:19:48 -0500

On December 21, 2017 at 9:39:49 AM, [email-masked] (
[email-masked]) wrote:

I see that you have also added the “note” on for the VPN routes. I don’t
think it’s necessary here as:

- if both routes are VPN ones, they are both labelled and are comparable as
per regular BGP/MPLS IP VPN routes

- if only the “policy” route is installed in the VRF (VRF fallback to the
main FIB), only the labeled VPN routes is considered, hence preferred.

Bottom line, I think that the note can be removed in the VPN section (5.4).
But nothing urgent, this can wait for a next update.

Hi!

I’m waiting for that next update to approve publication…

Alvaro.

---

From: "Gaurav Dawra (gdawra)" <[email-masked]>
Date: Thu, 21 Dec 2017 15:26:55 +0000

Alvaro,

Done! Thanks.

Cheers,

Gaurav

From: Alvaro Retana <[email-masked]>
Date: Thursday, December 21, 2017 at 7:19 AM
To: Gaurav Dawra <[email-masked]>, Bruno Decraene <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: [spring] AD Review of draft-ietf-spring-segment-routing-central-epe-06

On December 21, 2017 at 9:39:49 AM, [email-masked]<mailto:[email-masked]> ([email-masked]<mailto:[email-masked]>) wrote:

Hi!

Alvaro.