Subject: [spring] Re: WG Adoption Call for draft-agrawal-spring-srv6-mpls-interworking
From: Boris Hassanov <[email-masked]>
To: SPRING WG <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Fri, 19 Jul 2024 22:26:08 +0000 (UTC)
List-Id: "Source Packet Routing in NetworkinG (SPRING)" <spring.ietf.org>

Hi Bruno and all,

I read the draft and support it's adoption because it is obviously very important work for practical SRv6 migrations or introduction/co-existence with  MPLS/SR-MPLS technologies.
It is worth to continue this work from my (customer) point of view to have practical, deployable and standard MPLS/SR-MPLS<-> SRv6 interworking.

Here are the few minor (more cosmetic) points which I want to mention after reviewing the draft:
1)  Section 4. SRv6 SID behavior.
1.1)  4.1 End.DTM
....
S03.    Set the packet's associated FIB table to T
...
I would like to see some clarification, what is T here?
2)  Section 6. Interconnecting Binding SID.
I would add here the reference for RFC 9256 Section 6 that have a lot of information about BSID usage so will be quite helpful here too.
3)  I think it will be worth to move section 2 Interworking (IW) scenarios with Fig.1 Close to section 7, currently it is hard to jump back and worth while reading the text in section 7 Interworking procedures.
4) 7.1 Transport IW

This sentence: " An SR-PCE [RFC8664] multi-domain On Demand Next-hop (ODN) SR policy [RFC9256] stitching end to end across different data plane domains using interconnecting binding SIDs. " sounds too complicated  and confusing IMO and also does not mention additional scenarios which can accomplish the same goal as PCECC. I would re-phrase, for example, like this: "An SR-PCE [RFC8664]  based architecture with additional  functionality such as SR policy [RFC9256]  or PCECC [RFC8283] with corresponding PCEP extensions and feature like On Demand Next-hop (ODN)  can provide end to end stitching across different data plane domains using interconnecting binding SIDs"

5) 7.1.2.1 6oM
It is almost impossible to get the Control Plane example without any diagram there.

6) Same as above for 7.1.2.2.1 
I understand that making such ASCII-art is a tough task but  it will make reading much easier.

7) 7.2.1 Gateway interworking
I would re-phrase two last paragraphs (Prefix learned...) they are very complicated for reading.

SY,
Boris

On Thursday, July 11, 2024 at 04:28:19 PM GMT+3, <[email-masked]> wrote: 

  

Dear WG:

This message starts a three-week adoption call for

draft-agrawal-spring-srv6-mpls-interworking, ending on August/1rst.

(The third week is to account for the busy IETF week.)

>From the Abstract:

This document describes SRv6 and MPLS/SR-MPLS interworking and co- existence procedures.

 

Please review the draft and consider whether you support its adoption

by the WG. Please share any thoughts with the list to indicate support

or opposition -- this is not a vote.

If you are willing to provide a more in-depth review, please state it

explicitly to give the chairs an indication of the energy level in the

working group willing to work on the document.

WG adoption is the start of the process. The fundamental question is

whether you agree the proposal is worth the WG's time to work on and

whether this draft represents a good starting point. The chairs are

particularly interested in hearing the opinions of people who are not

authors of the document.

Draft: https://datatracker.ietf.org/doc/html/draft-agrawal-spring-srv6-mpls-interworking

List discussion: https://mailarchive.ietf.org/arch/browse/spring/?q=subject%3A%20draft-agrawal-spring-srv6-mpls-interworking

 

Thanks!

Bruno (for the Chairs)

_________________ ______________________________ ______________________________ ______________________________ _
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 -- [email-masked]
To unsubscribe send an email to [email-masked]