Hey Bruno,

Thanks for the review. Please see inline [Gaurav_2]

Regards,

Gaurav

From: Bruno Decraene <bruno.decra...@orange.com>
Date: Thursday, December 21, 2017 at 3:06 AM
To: Gaurav Dawra <gda...@cisco.com>, Alvaro Retana <aretana.i...@gmail.com>
Cc: "spring@ietf.org" <spring@ietf.org>, "spring-cha...@ietf.org" 
<spring-cha...@ietf.org>, 
"draft-ietf-spring-segment-routing-central-...@ietf.org" 
<draft-ietf-spring-segment-routing-central-...@ietf.org>
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:gda...@cisco.com]
Sent: Tuesday, December 19, 2017 8:01 AM
To: Alvaro Retana; draft-ietf-spring-segment-routing-central-...@ietf.org
Cc: spring@ietf.org; spring-cha...@ietf.org; 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 <aretana.i...@gmail.com<mailto:aretana.i...@gmail.com>>
Date: Friday, November 3, 2017 at 7:33 AM
To: Gaurav Dawra <gda...@cisco.com<mailto:gda...@cisco.com>>, 
"draft-ietf-spring-segment-routing-central-...@ietf.org<mailto:draft-ietf-spring-segment-routing-central-...@ietf.org>"
 
<draft-ietf-spring-segment-routing-central-...@ietf.org<mailto:draft-ietf-spring-segment-routing-central-...@ietf.org>>
Cc: "spring@ietf.org<mailto:spring@ietf.org>" 
<spring@ietf.org<mailto:spring@ietf.org>>, 
"spring-cha...@ietf.org<mailto:spring-cha...@ietf.org>" 
<spring-cha...@ietf.org<mailto:spring-cha...@ietf.org>>, Bruno Decraene 
<bruno.decra...@orange.com<mailto:bruno.decra...@orange.com>>
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) 
(gda...@cisco.com<mailto:gda...@cisco.com>) 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.
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Reply via email to