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:[email protected]] On Behalf Of
[email protected]
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:[email protected]] 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:[email protected]] 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 <[email protected]>
wrote:
Shuping,
Please add draft-bonica-spring-sr-mapped-six as a candidate for adoption.
Ron
Juniper Business Use Only
From: spring <[email protected]> On Behalf Of [email protected]
Sent: Friday, December 20, 2019 11:58 AM
To: 'SPRING WG List' <[email protected]>
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
[email protected]
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.
_______________________________________________
spring mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/spring
