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

["Gaurav Dawra (gdawra)" <[e-mail]>]

Hey Bruno,

Thanks for the review. Please see inline [Gaurav_2]

Regards,

Gaurav

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

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:[e-mail]]
Sent: Tuesday, December 19, 2017 8:01 AM
To: Alvaro Retana; [e-mail]
Cc: [e-mail]; [e-mail]; DECRAENE Bruno IMT/OLN; Gaurav Dawra (gdawra)
Subject: Re: [spring] AD Review of draft-ietf-spring-segment-routing-central-epe-06

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 <[e-mail]<mailto:[e-mail]>>
Date: Friday, November 3, 2017 at 7:33 AM
To: Gaurav Dawra <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, Bruno Decraene <[e-mail]<mailto:[e-mail]>>
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) ([e-mail]<mailto:[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.


...

[…]
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.

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

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





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.

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



Cheers,



Gaurav



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.