Re: [spring] draft-anand-spring-poi-sr

[<[e-mail]>]

Madhukar, authors,

Speaking as individual contributor, trying to help.

Thanks for the updated draft, which has improved over time.

The subject covers both optical and IP routing parts. Unfortunately, those subjects are typically covered in different WGs and by different people, so coming from a different history. This usually does not help and becomes worse when defining needs concept, such as 'POG'.

For presenting to IP routing folks (e.g., SPRING, LSR, IDR), I would suggest presenting from the IP routing aspect.
My reading & translation would be:
- the SR node has multiple links toward an adjacent SR node, with different optical characteristics. ('Adjacent' as per IGP adjacency in the SR/packet IGP)
- We want to associate a different SID to each link, such that an headend SR node could use an SR routing policy in order to steer a packet flow over a specific link. [1]
- We propose to use BGP-LS to advertise this SID and its characteristics.

[1] Whether we call the SID a 'Transport SID' or a 'Binding SID' or an 'Adjacency SID' is to be discussed.

If the above is a correct summary,


a)      I think the IDR WG would be a good home to introduce the above summary and the BGP-LS extension.
(I could have comments on those, such as why not reusing BGP-LS Adjacency SID TLV in order to advertise your SID, adding TLV/sub-TLV for you additional information e.g. Domain ID, Transport Segment Sub TLVs, but they would be individual comment belonging to the IDR WG. Probably same comment for the PCE extension)


b)      If you need to also cover the optical domain and the PCE protocol, may be the PCE WG would be a good home for that part.


c)       Now do you need something specific from the SPRING WG?
Except may be the above terminology point, especially if you really need to define something different such as 'Transport SID'. But why not reusing existing type of SIDs, e.g., Adjacency SID?
Then you are proposing to re-use the SR-Policy concept and apply it to your Transport policy use case. This is usually  a good think, thank you. However, I’m not completely certain that this is a perfect fit (very open question) E.g. you want a different SID per path while the SR policy wants the same SID for all paths

“Each TSR policy is associated with one or more candidate paths, each of them associated with a (locally) unique Binding SID”

https://tools.ietf.org/html/draft-anand-spring-poi-sr-08#section-5



“Candidate Paths of the same SR policy SHOULD have the same BSID.”

https://tools.ietf.org/html/draft-ietf-spring-segment-routing-policy-06#section-6.1




So may be all you need is Adjacency SIDs associated with additional (optical specifics) capabilities (Domain ID, Transport Segment Sub TLVs)?


Regards,
--Bruno
From: spring [mailto:[e-mail]] On Behalf Of [e-mail]
Sent: Wednesday, January 8, 2020 1:26 PM
To: Jeff Tantsura
Cc: SPRING WG List
Subject: [spring] draft-anand-spring-poi-sr

[changing the thread subject from ‘Re: [spring] WG status - pending calls” to ‘draft-anand-spring-poi-sr’]
Jeff,

      >From: spring [mailto:[e-mail]] On Behalf Of Jeff Tantsura

Ø  Please also add draft-anand-spring-poi-sr-08.

On that draft, I’ve spent quite some time with the authors in order to have that draft clarified, both face to face and through emails. This was partly before you joined the set of authors.
At that time, I didn’t believe the draft was ready for adoption, explained the reasons, sent comments, tried to understand the motivation & solution and improve the draft.

The draft has been significantly improved, thank you Anand. But IINM the ball is still on authors side. Latest email from one author is the following


Ø  Sent: Tuesday, January 29, 2019 6:28 PM
[…]

Ø  Hi Bruno,


Ø  Apologies for our delayed response. We just uploaded a new draft that tries to address your comments. I’ll respond to your comments soon.


Ø  Thanks,


So I’m waiting for the answers to my comments/emails. My review was from Tuesday, October 16, 2018 so after more than a year, everybody has lost context.

I’d also encourage comments, discussion and review from the SPRING WG.

Restating a meta comment, I think the draft could be clearer if you didn’t have to define the POG (Packet optical gateway) terminology which I don’t find crystal clear in the SPRING context.

   “The concept of POG introduced here allows for multiple instantiations
   of the concept. In one case, the packet device is distinct from the
   transport/optical device, and the POG is a logical entity that spans
   these two devices. In this case, the POG functionality is achieved
   with the help of external coordination between the packet and optical
   devices. In another case, the packet and optical components are
   integrated into one physical device, and the co-ordination required
   for functioning of the POG is performed by this integrated device.
   It must be noted that in either case, it is the packet/optical data
   plane that is either disaggregated or integrated. Control of the
   devices can be logically centralized or distributed in either
   scenario.  The focus of this document is to define the logical
   functions of a POG without going into the exact instantiations of the
   concept. »
https://tools.ietf.org/html/draft-anand-spring-poi-sr-08#section-1

It’s not certain that the SPRING WG is the best home

-           “to define the logical functions of a POG without going into the exact instantiations of the concept.”

-           restating my previous comment “ it would be good to present the document both in PCE and TEAS, in order to collect their feedback.” Which IINM is also pending an answer  (beyond “Please note Madhukar's new email address.”)

-          SPRING related content seems in section 5 [1]. But it’s not immediately apparent what the document is specifying in addition to the SR policy [2]
[1] https://tools.ietf.org/html/draft-anand-spring-poi-sr-08#section-5
[2] https://tools.ietf.org/html/draft-ietf-spring-segment-routing-policy-06#section-2

On the other hand, the document is defining PCE and BGP-LS protocol extension.
So one option would be to discuss this document in the PCE WG and for SPRING related aspects build upon existing SPRING constructs, in particular SID, Binding SID and SR Policy.
Another option would be to discuss this document in the IDR WG as it seems mostly defining BGP-LS extensions.

So again, I would encourage you to present to the PCE WG and to the IDR WG for BGP-LS related extensions.

Thank you,
--Bruno

From: spring [mailto:[e-mail]] On Behalf Of Jeff Tantsura
Sent: Saturday, December 21, 2019 11:27 PM
To: SPRING WG List
Subject: Re: [spring] WG status - pending calls

Shuping,

Please also add draft-anand-spring-poi-sr-08.


Thanks and happy holidays!

Regards,
Jeff


On Dec 21, 2019, at 12:37, Ron Bonica <rbonica=[e-mail]> wrote:

Shuping,

Please add draft-bonica-spring-sr-mapped-six as a candidate for adoption.

                                                                       Ron




Juniper Business Use Only
From: spring <[e-mail]> On Behalf Of [e-mail]
Sent: Friday, December 20, 2019 11:58 AM
To: 'SPRING WG List' <[e-mail]>
Subject: [spring] WG status - pending calls

Hi SPRING,

A number of authors have asked for their document to be adopted or last called.
Chairs have some backlog on this. The WG has also been pretty busy over the last 6 months with a set of subjects triggering many emails and this is not always the best time to ask for review of additional documents (versus short ‘+1’).
Chairs/WG will work on this calls in 2020. In the meantime, for a better transparency, Shuping has been kind enough to track this on the wiki https://trac.ietf.org/trac/spring<https://urldefense.com/v3/__https:/trac.ietf.org/trac/spring__;!!NEt6yMaO-gk!TG5-O8kd2fVPxVkN2IRvaGLVHkQ6cSPlDhE0xNBRC23Go4mlw3dAbBCJR3JqSYly$> Thank you Shuping.
If your document is missing from the list of pending calls for adoption/last call, please send an email to the chairs or to the list, as you wish.
Otherwise, your request is been tracked.

Content of this page is subject to change. In particular, the goal is not to duplicate the information already tracked in the ietf datatracker. E.g. https://datatracker.ietf.org/doc/search?name=&sort=&activedrafts=on&by=group&group=spring<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/search?name=&sort=&activedrafts=on&by=group&group=spring__;!!NEt6yMaO-gk!TG5-O8kd2fVPxVkN2IRvaGLVHkQ6cSPlDhE0xNBRC23Go4mlw3dAbBCJR469-5yL$>

I take this opportunity to wish everyone Merry Christmas, an Happy New Year and possibly Happy Holidays.
--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
[e-mail]
https://www.ietf.org/mailman/listinfo/spring

_________________________________________________________________________________________________________________________



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.

_________________________________________________________________________________________________________________________

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.