Re: [spring] Small SID/Compressed SID Design Team

[Gyan Mishra <[e-mail]>]

Very welcome. Glad to hear that the DT is making good progress and sounds
like on target to the dates Bruno mentioned.

Thank you for the Github link

Kind Regards

Gyan

On Wed, Sep 30, 2020 at 3:28 AM Weiqiang Cheng <
[e-mail]> wrote:

> Hi Gyan,
>
> Thank you for your comments to the design team.
>
> The design team works according to the roadmap as Bruno mentioned.
>
> The progress is so far so good. We have finished the first version of the
> requirement draft by Sep. 20th.
>
>
>
> But, we realized that we need more time to finish the detailed review
> within Design Team.
>
> Now we have twice meeting per week and hope we can post the draft before
> the deadline of IETF 109 submission.
>
>
>
> We create a git-hub space to trace the work of the DT, and you can find
> the meeting minutes and documents under discussion.
>
> Please access following link, if you hope to get more information.
>
> https://github.com/IETF-srcomp/documents
>
>
>
> B.R.
>
> Weiqiang Cheng
>
>
>
> *发件人:* [e-mail] [mailto:[e-mail]]
> *发送时间:* 2020年9月28日 16:43
> *收件人:* Gyan Mishra; 程伟强; sander
> *抄送:* [e-mail]; [e-mail]; James Guichard
> *主题:* RE: [spring] Small SID/Compressed SID Design Team
>
>
>
> Hi Gyan,
>
>
>
> *From:* Gyan Mishra [mailto:[e-mail]]
> SID Design Team
>
>
>
>
>
> Hi Jim, Bruno & Joel
>
>
>
> I was wondering if it would be possible to provide a brief synopsis or
> debriefing of where we stand thus far with deliberations on Small SID /
> Compression SID design team results.
>
>
>
> I think that this is fair to leave this to the chairs of the DT. I have
> asked them to provide an update of their planning to the WG.
>
>
>
> Also an ETA for the WG as to when this project will be wrapped up and the
> compression technique to be used with SRV6 finalized.
>
>
>
> Dates may be set to DT and WG (e.g., via WG milestones), but in an
> organization where people work on a voluntary basis, I would not call those
> dates “ETA”.
>
> And even before the notion of ETA (I’m guessing your emphasis is on
> ‘Time’), there is the question of ‘Arrival’. (and even before, the question
> of ‘Destination’(s)… ).
>
> The journey would probably be more effective if we all work together on
> the achievement, rather than working side by side with different sub groups
> each working a different destination. This may require a change of paradigm
> from “I want my solution to advance (quickly)” to “I want a solution to
> advance (quickly)”. Alternatively, there would be multiple destinations and
> multiple ETAs.
>
>
>
> Coming back to the ETA,
>
> -          To kick of the WG work, we have set a design team to work and
> deliver two documents.
>
> -          In IETF 108, the DT has presented a planning to the WG.
>
> -          Following one feedback from the WG, WG chairs have asked the
> DT to see if they could increase the level of effort and deliver faster.
> They have gently agreed and provided an updated roadmap. Thank you for
> their work, since they are the one doing the work.
>
> -          I now realize that this new roadmap has not been sent to the
> WG list. Sorry for that. Please find below
>
> o   Stage 1: Prepare the requirement draft by end of September
>
> o   -           Phase 1:  rough requirements list with several different
> categories, by 20th of Aug.
>
> o   -           Phase 2:  one week for review by end of Aug.
>
> o   -           Phase 3:  finish the draft by 20th of Sep.
>
> o   -           Phase 4:  one week for review by end of Sep.
>
> o   -           Phase 5:  Post it to WG and present it at IETF 109
>
> o      Discussion order: follow the time of items.
>
> o
>
> o   Stage 2: Prepare the analysis draft by end of November (expected
> time, Let us talk about the schedule after the first draft finished.)
>
> o   -           Input: existing drafts by end of September
>
> o   -           Polling the drafts in WG mail list from Sep 1st to Sep
> 30th and ensure all the existing drafts counted in.
>
> -          Based on the above, with a draft planned for end of September,
> WG chairs had planned to set up a virtual interim meeting, around mid
> October. (leaving two weeks for the WG to read and review the draft).
>
> -          As of today, the above agenda is at risk. As we were planning
> the virtual interim meeting with the DT, they replied that they were now
> planning their first draft for November 4.
>
>
>
> My suggestion is that with the finalized compression technique feature,
>  in order to provide complete parity as well as transparency with SRv6,
>  but also more importantly make it holistic as well as seamless the change
> to operators, it would be good if this is made part of the base SRv6
> architecture and not a separate add on patch or workaround separate feature
> if possible.  This would make it as if SRv6 architecture had the
> compression technique all along built into the architecture.  This would
> overall be very positive for SRv6.  I think to accomplish this would
> require updating the main SR architecture RFC 8402 and RFC 8754 and PGM
> draft referencing the new compression technique as part of the inherent
> architecture framework.
>
> Suggestion noted.
>
> I wish we were there, but the WG needs to first deliver on “the finalized
> compression technique feature”. And if we end up with N solutions, the
> above may be more difficult to perform and achieve.
>
>
>
> Kind regards
>
> --Bruno
>
>
>
> Kind Regards
>
>
>
> Gyan
>
>
>
>
>
> On Tue, Jun 30, 2020 at 12:30 PM James Guichard <
> [e-mail]> wrote:
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Dear SPRING WG:
>
>
>
>
>
>
>
> The WG chairs have been working with the relevant ADs to determine what
> needs to be done to move the SPRING segment routing work related to IPv6
> along effectively. We are going to establish a design team as soon as
> possible, with a specific
>
> objective to look at the compression-related work.
>
>
>
>
>
>
>
> The design team charge is still being worked on, but roughly it will be
> tasked to agree on a requirements proposal to the WG and a comparison
> document to be evaluated by the WG.  To be clear, as is the normal case for
> the IETF, the design
>
> team outputs are input to the WG.  Their output will not become a WG
> document until the WG agrees to adopt it.  Also, these documents are for WG
> use.  It will be for future analysis as to whether it is useful to the
> larger community to publish them as RFCs.
>
>
>
>
>
>
>
> While we have various thoughts as to membership in the design team, we
> would like proposals for people we should include. We expect that there are
> more people that we "should" include than can make up an effective design
> time for the rapid
>
> delivery that we need.  If you are willing to serve on the design team,
> please let the chairs know. If there is someone you think would be good on
> the design team, please ask them to let us know.  We are NOT soliciting
> evaluations of proposed people on the
>
> list.  So, it is best if volunteers come to us directly. To be explicit,
> the chairs will select the members of and the chair for this design team.
>
>
>
>
>
>
>
> We hope to appoint a small, effective, team that represents the varied
> interests and concerns that have been expressed on the list.  Folks
> volunteering should understand that we hope you can move quickly, so it
> will take a significant amount
>
> of your time. The deadline for volunteering is 6pm US PST this coming
> Friday.
>
>
>
>
>
>
>
> Thanks!
>
>
>
>
>
>
>
> Jim, Joel & Bruno
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
>
> spring mailing list
>
> [e-mail]
>
> https://www.ietf.org/mailman/listinfo/spring
>
> --
>
> <http://www.verizon.com/>
>
> *Gyan Mishra*
>
> *Network Solutions Architect *
>
>
>
> *M 301 502-134713101 Columbia Pike *Silver Spring, MD
>
>
>
> _________________________________________________________________________________________________________________________
>
>
>
> 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.
>
>

-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *



*M 301 502-134713101 Columbia Pike *Silver Spring, MD