Re: [spring] Working Group Adoption Call for draft-cheng-spring-mpls-path-segment

Hi Ketan, 

Thank you for your support and comments, please see my reply inline.

Regards,
Cheng

-----Original Message-----
From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Ketan Talaulikar (ketant)
Sent: Wednesday, February 27, 2019 12:20 PM
To: bruno.decraene@orange.com; SPRING WG <spring@ietf.org>
Cc: draft-cheng-spring-mpls-path-segment@ietf.org
Subject: Re: [spring] Working Group Adoption Call for draft-cheng-spring-mpls-path-segment

Hello,

I support the adoption of this draft by the WG. I have some comments which I would like to bring to the author's and WG though - some of these were raised when this draft was presented in Bangkok but I don't see them addressed as yet.

1) Sec 2.
A Path Segment is a single label that is assigned from the Segment
   Routing Local Block (SRLB) or Segment Routing Global Block (SRGB) of
   the egress node of an SR path.

KT> Why can't the Path Segment be allocated from the dynamic MPLS label pool on the egress node? Can this be added as discussed in Bangkok? This mode would help achieve a good scalability for SR Policies along with the option of using SRLB. On the other hand, I do not understand the use-case for allocating Path Segments from the SRGB. If there is none, do we want to preclude SRGB usage for Path Segments?

[Cheng] Yes, path segment can be allocated from dynamic MPLS lable pool as we answered you at Bangkok. We will add text to specify that. Regarding SRGB, We won't suggest to allocate path segment from SRGB due to scalability consideration, but we don't stop people to do that.

2) Can the authors clarify on the relationship and usage of Path Segment with Entropy label (https://tools.ietf.org/html/draft-ietf-mpls-spring-entropy-label-12)? There are examples of nested segments. Similarly, the draft could use some text to discuss the MSD capabilities of the headend when enabling path segment usage.

[Cheng] Regarding EL, I think it can be pushed before or after path segment, it does not matter. But we would suggest to place path segment before EL.
Only need to make sure that path segment to be read by the egress node.
Thus, it should be placed after the "routing segment（adj/node/prefix）" pointing to the egress node.

Thanks, will add text to describe MSD.

3) This seems SR/MPLS specific to me. Is that correct? If so, why put reference to SRv6 documents in there as that would create confusion?
[Cheng] Correct, will delete those references.

Thanks,
Ketan

-----Original Message-----
From: spring <spring-bounces@ietf.org> On Behalf Of bruno.decraene@orange.com
Sent: 20 February 2019 14:34
To: SPRING WG <spring@ietf.org>
Cc: draft-cheng-spring-mpls-path-segment@ietf.org
Subject: [spring] Working Group Adoption Call for draft-cheng-spring-mpls-path-segment

Hi SPRING WG,

This email initiates a two week call for working group adoption for draft-cheng-spring-mpls-path-segment.

Please indicate your support, comments, or objection, for adopting this draft as a working group item by March 6th 2019.
We are particularly interested in hearing from working group members that are not co-authors of this draft.
We are also looking for volunteers who would be ready to perform a technical review of this work at some later stage, such as before or during WG the last call.

Additionally, there are currently 7 authors listed on this document. Please trim this to <= 5 front-page authors, utilising a "Contributors" section if required for the others. An approach to achieving this would be to list ~2 editors as the front-page authors.

In parallel to this adoption call, I will send an IPR call for this document. We will need all authors and contributors to confirm their IPR position on this document.

(1) https://tools.ietf.org/html/draft-cheng-spring-mpls-path-segment

Thanks,
--Bruno & Rob.

_________________________________________________________________________________________________________________________

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

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