Re: [spring] IPR Disclosures for draft-ietf-spring-bfd

Alvaro,I’m not aware for any IPR that applies to the draft.Cheers,JeffOn May 2, 2024, at 07:48, iLya Varlashkin wrote:I’m not aware of any undisclosed IPR related to this draft.Kind regards,iLya VarlashkinOn Wed, 24 Apr 2024 at 08:17 Greg Mirsky wrote:I am not aware of

Re: [spring] [WARNING: SUSPICIOUS SENDER] Request comments/feedback on https://datatracker.ietf.org/doc/draft-zzhang-spring-microtap-segment/01/

Seems like a very useful feature indeed.Cheers,JeffOn Feb 27, 2024, at 07:15, Ryan Hoffman wrote:TELUS intends to deploy this microTap segment feature once available in vendor NOS after thorough testing in our lab.  We'd expedite TELUS testing and deployment when available from vendors, as this

Re: [spring] Proposed policy on reporting implementation and interoperability

Very much in support of the proposal.I’d expect to see all and each MUST statements implemented for an implementation to be able to claim to be 100% compliant with the specification.MAY/SHOULD could be implemented or not, however should be addressed in the implementation report, additional (and

Re: [spring] [bess] [Pals] [EXTERNAL] Re: Martini Pseudowires and SR

+1 Jorge at all. I don’t foresee significant additions to RFC 8214, most legacy PALS stuff doesn’t need to be resurrected.  However - If there’s appetite for IGP extensions for signaling PW (in spirit of SR)) and  (rather than using LDP)  there’s that – “Method and apparatus for pseudo-wire setup

Re: [spring] IPR Disclosure Cisco Systems, Inc.'s Statement about IPR related to RFC 8402

To my memory, Redback (Albert Tian) published draft-tian-mpls-lsp-source-route aroun 2004 and filed IPR a year or so before that ;-) Cheers, Jeff > On Apr 18, 2022, at 15:58, Tony Li wrote: > >  > Let me see if I understand the timeline here: > > 2013, June 28, Draft submission of

Re: [spring] WGLC for draft-ietf-spring-segment-routing-policy

Boris/Ketan, Traditionally, we have been using Wiki to track implementations status, let’s take the same approach here? Thanks and have a great weekend Cheers, Jeff On Apr 27, 2021, 10:48 PM -0700, Ketan Talaulikar (ketant) , wrote: > Hi Boris, > > Thanks for your review and feedback. > > Did

Re: [spring] FW: New Version Notification for draft-bonica-spring-srv6-end-dtm-01.txt

d with a next hop. A > recursive lookup may be required to derive the next hop from the topmost > label stack entry." > > Ron > > > > Juniper Business Use Only > > -Original Message- > From: Loa Andersson > Sent: Monday, February 8, 2021 11:51 PM > To

Re: [spring] IPR call for draft-ietf-spring-nsh-sr

Hi Bruno, As a co-author I am not aware of any undisclosed IPR. Thanks! Cheers, Jeff ___ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring

Re: [spring] FW: New Version Notification for draft-bonica-spring-srv6-end-dtm-01.txt

Hi Ron, Very useful document, thanks! Question wrt processing: As described in the draft: “A SID instance is associated with SR-MPLS label stack and outgoing interface.” I’d think that outgoing interface would be recursively resolved based on the top SID (and could change based on topological

Re: [spring] WG Adoption Call for https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11

Yes/support Regards, Jeff > On Oct 27, 2020, at 19:26, Stefano Salsano > wrote: > > I support the adoption of this document > > FYI, we've used a previous version of this document and we've done an > implementation and setup a testbed, please see results described in: > > P. Loreti et.

Re: [spring] IPR related to draft-mirsky-spring-bfd

+1 , not aware of any IPR applicable. Cheers, Jeff On Sep 22, 2020, 12:10 PM -0700, Greg Mirsky , wrote: > Dear All, > please note that I am not aware of any IPR that applies to this document. > > Regards, > Greg ___ spring mailing list spring@ietf.org

Re: [spring] The SPRING WG has placed draft-mirsky-spring-bfd in state "Call For Adoption By WG Issued"

I support the adoption as co-author, for the reasons outlined by Greg. Cheers, Jeff On Sep 14, 2020, 2:17 PM -0700, Greg Mirsky , wrote: > Dear All, > I support the adoption of draft-mirsky-spring-bfd by the SPRING WG for the > following reasons: > > • optional control of the reverse path of the

Re: [spring] to drop or to forward unlabelled (Re: Question on RFC8660)

I’m with Bruno here, and the spec is quite clear on the behavior expected (implementors, please speak up). Given variability and interdependencies in use cases, I’d say, drop should be (and de-jure it is) the default behavior, and if someone wants their vendor of choice to implement a knob to

Re: [spring] [Lsr] draft-tgraf-ipfix-mpls-sr-label-type

In general, I agree with what Ketan said, what’s important - it is the value that is being used in forwarding, even if multiple control plane entries exist, think about IGP migrations, or LDP to SR, where more than 1 protocol could be distributing the labels/SIDs. I’m not sure the FIB is the

Re: [spring] WG adoption call for draft-hegde-spring-node-protection-for-sr-te-paths

yes/support Cheers, Jeff On Jul 30, 2020, 5:25 AM -0700, bruno.decra...@orange.com, wrote: > Hi SPRING WG, > > Authors of draft-hegde-spring-node-protection-for-sr-te-paths  [1] have asked > for WG adoption. > > Please indicate your support, comments, or objection, for adopting this draft > as

Re: [spring] WG Adoption Call for draft-raza-spring-srv6-yang

Very much with Dhruv here. While the work is important and should be progressing, overall quality could be significantly improved. Please use draft-ietf-spring-sr-yang as the example. Regards, Jeff > On Jul 25, 2020, at 10:22, Dhruv Dhody wrote: > > Hi WG, > > I support the adoption of this

Re: [spring] WG Adoption Call for draft-dong-spring-sr-for-enhanced-vpn

Yes/support Regards, Jeff > On Jul 15, 2020, at 04:17, James Guichard > wrote: > >  > Dear WG: > > This email begins a 2 week WG adoption call for > https://datatracker.ietf.org/doc/draft-dong-spring-sr-for-enhanced-vpn/ > ending Wednesday 29th July 2020. > > Please speak up if you

Re: [spring] Understanding the replication draft

> > > > nodes would have to agree on one common service label. So P2MP > > > > services implicitly map the P2MP transport label (Replication SID > > > > at BoS in this case) to the P2MP service. Of course, this implies > > > > one-to-one association b

Re: [spring] Understanding the replication draft

Rishabh, Transport SID with a service on top can’t be a BoS label, there’s s service label below, since a service is associated with a particular node, there would be at least a N-SID associated with the service node. It seems like B-SID behavior is the correct one, when R-SID is looked up and

Re: [spring] Spring SR question??

Gyan, In SR-MPLS, either over IPv4 or IPv6 the data-plane is MPLS (rfc8660) If MPLS is tunneled over IP, e.g MPLS over GRE, MPLS over UDP, etc, then data-plane is that of outer encapsulation - rfc8663 as the best example, e.g outer header would be IPv4/IPv6+UDP Since bindings (SIDs) need to be

Re: [spring] WG LC https://datatracker.ietf.org/doc/draft-ietf-spring-sr-yang/

Support as co-author Cheers, Jeff On Jun 23, 2020, 10:59 AM -0700, James Guichard , wrote: > Dear SPRING WG: > > This email starts a two week WG LC for > https://datatracker.ietf.org/doc/draft-ietf-spring-sr-yang/. > > Substantive comments should be directed to the mailing list no later than >

Re: [spring] WG adoption call for draft-voyer-spring-sr-replication-segment

Support the adoption, willing to work on this document as well as on IDR/PCE related ones. Cheers, Jeff On Jun 22, 2020, 10:46 AM -0700, bruno.decra...@orange.com, wrote: > > Hi SPRING WG, > > Authors of draft-voyer-spring-sr-replication-segment [1] have asked for WG > adoption. > > Please

Re: [spring] Leadership change

Thanks Rob! Welcome Jim and Joel! Cheers, Jeff On Jun 14, 2020, 1:25 PM -0700, Martin Vigoureux , wrote: > WG, > > Rob had decided to step down as chair some time ago. There hasn't been > any formal communication on that so I'd like, first, to thank Rob for > his work and dedication to the

Re: [spring] WGLC - draft-ietf-spring-srv6-network-programming (off-topic)

As Robert mentioned, it is quite often the case for a chair to participate in the development of a draft. Taking RTGWG as an example, when we got (as result of a merge) a draft that both Chris and myself have co-authored, we had RTGWG secretary taking care of the life cycle of the draft. I’m

Re: [spring] WGLC - draft-ietf-spring-srv6-network-programming

I second Carlos. Besides, Bruno's integrity is well known! It is a common practice however, when one of the chairs is a co-author of a document that is progressing in the working group chaired, for the second chair to manage the document in question. Cheers, Jeff On Feb 28, 2020, 5:15 PM -0800,

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 > wrote: > >  > Shuping, > > Please add draft-bonica-spring-sr-mapped-six as a candidate for adoption. > >

Re: [spring] Different MSDs for different traffic types on the same headend.

for SRv6, perhaps different interfaces rather than dual stack > > In-line questions follow up > > > On Tue, Dec 17, 2019 at 8:41 PM Jeff Tantsura > > wrote: > > > Gyan, > > > > > > I wrote this presentation ~3 years ago, so the numbers are not >

Re: [spring] Different MSDs for different traffic types on the same headend.

d that can perform 1 of the following 2 modes(but > > > > > not both): > > > > > 1) Plain IPv4: 6 transport labels + 0 service label => traffic can be > > > > > steered into a 6-label SR-TE policy. > > > > > 2) Any type of VPN: 3 transport

Re: [spring] Different MSDs for different traffic types on the same headend.

gt; > cannot be steered into a 6-label SR-TE policy. > > > a) As defined in RFC8491, the BMI-MSD is 6 for this headend. Do we have a > > > standardized way to signal the transport label depth in mode 2? > > >    Maybe in a different MSD type? > > > b) Since p

Re: [spring] Different MSDs for different traffic types on the same headend.

; > > > > > > a) As defined in RFC8491, the BMI-MSD is 6 for this headend. Do we > > > > > have a standardized way to signal the transport label depth in mode 2? > > > > >    Maybe in a different MSD type? > > > > > b) Since plain IPv4 a

Re: [spring] Different MSDs for different traffic types on the same headend.

that exceeds the transport label > > > depth of the service route. I'm trying to figure out the standard > > > behavior in this case since the headend we use currently produces some > > > interesting results. > > > > > > Regards, > &

Re: [spring] Different MSDs for different traffic types on the same headend.

Hi Nat, Please read https://tools.ietf.org/html/rfc8491#section-5 Currently defined MSD types are: 1: BMI 2: ERLD Specifically to BMI: Base MPLS Imposition MSD (BMI-MSD) signals the total number of MPLS labels that can be imposed, including all service/transport/special labels. The answer to

Re: [spring] Fw: New Version Notification for draft-matsushima-spring-srv6-deployment-status-02.txt

ure it would use fast-rehash over ECMP rather that > > TI-LFA? > > Do you think that this is a good idea to consider using TI-LFA in a Clos > fabric ? > > Thx, > R. > > > On Fri, Oct 18, 2019 at 10:53 PM Jeff Tantsura > > wrote: > > > Hell

Re: [spring] Fw: New Version Notification for draft-matsushima-spring-srv6-deployment-status-02.txt

Hello Hirofumi, Many thanks for sharing the use case. Reading your slides, it looks like completely host based overlay design, e.g. no fabric switch is SRv6 aware, not using any of SRv6 functionality (TE, IPFRR, etc) and their solely function is to forward traffic towards destinations of

Re: [spring] [Idr] I-D Action: draft-ietf-idr-performance-routing-02.txt

Xiaohu, few comments: RFC7311 is very specific about containing routes with AIGP attribute within  AIGP administrative domain, while not well defined in RFC7311, perhaps worth saying something? The value field of the AIGP TLV in RFC7311 is 8 octets long - draft defines 4 octet value, I assume

Re: [spring] SR-MPLS over IPv6？

gt; Juniper Business Use Only > > From: Chengli (Cheng Li) > > Sent: Monday, September 23, 2019 10:14 PM > > To: Ron Bonica ; Jeff Tantsura > > > > Cc: SING Team ; EXT - daniel.bern...@bell.ca > > ; SPRING WG List > > Subject: RE: [spring] SR-MPLS over

Re: [spring] A note on CRH and on going testing

There’s number of solutions on the market that extensively use BSID for multi-domain as well as multi-layer signaling. Regards, Jeff > On Sep 19, 2019, at 19:49, Chengli (Cheng Li) wrote: > > +1. > > As I mentioned before, Binding SID is not only for shortening SID list. > We should see the

Re: [spring] “SRV6+” complexity in forwarding

Gyan, IPFRR doesn’t use/need any IGP extensions and is local to the device computing LFA. As RTGWG chair - I welcome you to read a number of rather well written RFCs on the topic we have published in RTGWG over the last 7 years. Pay attention on how LFAs are computed, this would clarify your

Re: [spring] Binding SID in SRv6/SRv6 (was: Beyond SRv6)

Ron, another, and quite important use of BSID in SR-MPLS is to provide an anchor point to another domain/layer and an abstraction to program this layer without understanding its semantics. SR/RSVP-TE or IP/Opto would be a perfect example of that, draft-anand-spring-poi-sr describes such case.

Re: [spring] WG Adoption Call: draft-xuclad-spring-sr-service-programming

Rob, I’m not aware of any IPR besides that already disclosed. Regards, Jeff > On Aug 4, 2019, at 15:12, Rob Shakir > wrote: > > SPRING, > > Thanks for the review of this document. As with the other document, apologies > for the delay in following up. Based on the mailing list replies,

[spring] IPR disclosure against draft-gandhi-spring-ioam-sr-mpls

Dear chairs, I have contacted E/// IPR department, they will file the IPR ASAP (US10356227) Cheers, Jeff ___ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring

Re: [spring] Managing "global" SIDs

Robert, Sure, my point was that you won’t need a “NMS per vendor” and hence a need to agree on control plane protocol (PCEP). Abusing control plane for configuration… been there :) Specifically to PCEP point - PCEP creates ephemeral state, (not persistent across reboots), and hence rather

Re: [spring] Managing "global" SIDs

All of the tasks described belong in management plane, while I’m not particularly fond of using DHCP, having single source of truth for configurational state is better than configuring box by box (and excel to manage it :)) Most SP’s (and as Stephane alluded) already have a centralized

Re: [spring] Seeking comments for draft-dunbar-sr-sdwan-over-hybrid-networks: is it appropriate for not-directly connect SDWAN edges to use GRE/VxLAN header bits to indicate the desired SR path?

SR edge. The draft > is suggesting VxLAN or GRE to connect the SDWAN edge and the SR edge. > > Linda > > From: Jeff Tantsura > Sent: Thursday, July 18, 2019 2:25 PM > To: spring ; SPRING WG ; 徐小虎(义先) > ; Linda Dunbar > Subject: RE: [spring] Seeking comments for > draft-dunbar-

Re: [spring] Seeking comments for draft-dunbar-sr-sdwan-over-hybrid-networks: is it appropriate for not-directly connect SDWAN edges to use GRE/VxLAN header bits to indicate the desired SR path?

based. > > So it should be reversed, IP segments -> SR segments which include both SRv6 > & MPLS-SR -> IP segments > > Linda > > From: Jeff Tantsura > Sent: Monday, July 15, 2019 5:48 PM > To: spring ; SPRING WG ; 徐小虎(义先) > ; Linda Dunbar > Subject: RE:

Re: [spring] Seeking comments for draft-dunbar-sr-sdwan-over-hybrid-networks: is it appropriate for not-directly connect SDWAN edges to use GRE/VxLAN header bits to indicate the desired SR path?

such as Forwarding entry Construction, forwarding > procedures as in draft-ietf-mpls-sr-over-ip? > > Linda > > From: Jeff Tantsura > Sent: Tuesday, July 09, 2019 4:03 PM > To: spring ; Linda Dunbar > ; SPRING WG ; 徐小虎(义先) > > Subject: Re: [spring] Seeking comm

Re: [spring] Seeking comments for draft-dunbar-sr-sdwan-over-hybrid-networks: is it appropriate for not-directly connect SDWAN edges to use GRE/VxLAN header bits to indicate the desired SR path?

+1 take a look at draft-ietf-mpls-sr-over-ip Cheers, Jeff On Jul 8, 2019, 11:45 PM -0700, 徐小虎(义先) , wrote: > Hi Linda, > > Why not directly use the MPLSoUDP encapsulation to carry the B-SID label so > as to indicate the preferred path? For more details, please read  >

Re: [spring] IPR Poll: draft-guichard-spring-nsh-sr

Not aware of any undisclosed IPR. Regards, Jeff > On Jun 27, 2019, at 01:13, Rob Shakir wrote: > > Hi Authors, SPRING WG, > > In parallel to the call for working group adoption for > draft-guichard-spring-nsh-sr we would like to poll for IPR. > > If you are aware of IPR that applies to

Re: [spring] [Lsr] Adjacency SID and Passive Interface

+1 Regards, Jeff > On May 10, 2019, at 05:22, Ketan Talaulikar (ketant) wrote: > > +1 > > Hi Oliver, > > Technically Adj-SID refers to an IGP adjacency between two nodes as per > RFC8402 semantics. I don't think a passive (stub) link falls under that > category. It would be better to

[spring] RP1 research paper Technical feasibility of Segment Routing Traffic Engineering to steer traffic through VNFs

the research paper mentioned at the mike Cheers, Jeff ___ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring

Re: [spring] Working Group Adoption Call for draft-filsfils-spring-srv6-network-programming

yes/support Cheers, Jeff On Mar 13, 2019, 11:49 AM -0700, bruno.decra...@orange.com, wrote: > Hi SPRING WG, > This email initiates a three week call for working group adoption for > draft-filsfils-spring-srv6-network-programming. (Three weeks to account for > the IETF week) > Please indicate

Re: [spring] IPR Poll for draft-cheng-spring-mpls-path-segment

to:spring-boun...@ietf.org] On Behalf Of > bruno.decra...@orange.com > Sent: Wednesday, February 20, 2019 5:02 PM > To: SPRING WG ; Jeff Tantsura ; > draft-cheng-spring-mpls-path-segm...@ietf.org > Subject: [spring] IPR Poll for draft-cheng-spring-mpls-path-segment > &g

Re: [spring] Last Call: (Segment Routing with MPLS data plane) to Proposed Standard

+1 Cheers, Jeff On Feb 26, 2019, 1:21 PM -0800, Adrian Farrel , wrote: > This draft has been around the block a bit, but certainly needs to progress > because a lot of other things are dependent on it. > > Fortunately after plenty of review and updates (thanks to the authors), I > think it is now

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

Hi, The draft defines useful functionality however doesn’t talk about implications wrt MSD (RFC8491/8476) PSID is an additional label in the stack, it has implications to the MSD signaling, PCE computation, what happens when egress expects PSID but ingress can’t impose one and similar cases.

Re: [spring] IPR Poll for draft-cheng-spring-mpls-path-segment

Bruno, Quick update - E/// IPR folks have responded and looking into this. Cheers, Jeff On Feb 22, 2019, 3:49 PM -0800, Jeff Tantsura , wrote: > Bruno, > > Please let me reach out to E/// IPR department (BCCed). > I’ll let them comment. > > Thanks > > Cheers, &

Re: [spring] IPR Poll for draft-cheng-spring-mpls-path-segment

Bruno, Please let me reach out to E/// IPR department (BCCed). I’ll let them comment. Thanks Cheers, Jeff > 原始邮件 > 发件人：bruno.decra...@orange.com > 收件人：SPRING WG ;Jeff Tantsura > ;draft-cheng-spring-mpls-path-segm...@ietf.org > ; > 日 期 ：2019年02月20日 17:02 > 主 题 ：IPR

Re: [spring] solicit feedback on draft-dunbar-sr-sdwan-over-hybrid-networks-02 proposing SD-WAN source node using UDP port to indicate to SR ingress node how to map to appropriate Binding SID

ubts about the technology proposed. Cheers, Jeff From: on behalf of Robert Raszuk Date: Monday, July 2, 2018 at 16:05 To: Jeff Tantsura Cc: Linda Dunbar , SPRING WG List Subject: Re: [spring] solicit feedback on draft-dunbar-sr-sdwan-over-hybrid-networks-02 proposing SD-WAN source node usin

Re: [spring] solicit feedback on draft-dunbar-sr-sdwan-over-hybrid-networks-02 proposing SD-WAN source node using UDP port to indicate to SR ingress node how to map to appropriate Binding SID

Robert, I don’t think “pooling” is the right word, there’s an explicit relationship between underlay and overlay. Cheers, Jeff From: spring on behalf of Robert Raszuk Date: Monday, July 2, 2018 at 14:50 To: Linda Dunbar Cc: SPRING WG List Subject: Re: [spring] solicit feedback

Re: [spring] solicit feedback on draft-dunbar-sr-sdwan-over-hybrid-networks-02 proposing SD-WAN source node using UDP port to indicate to SR ingress node how to map to appropriate Binding SID

Hi Linda, (not speaking as rtgwg chair, where you might want to present the draft) The scenario we are talking about is really - WAN (underlay/transport) controller interworking with SD-WAN (overlay) controller. Resource allocation could happen by either WAN controller pre-allocating

Re: [spring] Updating the SPRING WG Charter

Hi Bruno/Rob, Looks good, well done! Cheers, Jeff From: spring on behalf of Date: Thursday, June 28, 2018 at 08:52 To: SPRING WG List Subject: Re: [spring] Updating the SPRING WG Charter Hi SPRING, Following the discussion on the mailing list, please find below the updated

Re: [spring] Updating the SPRING WG Charter

Linda, “Legacy Networks” is a derogatory term used by OF bigots to call anything, that’s  distributed ☺ There’s nothing wrong with changing and evolving existing networking to be more programmable and flexible, changes are welcome. I don’t think we should call existing networking –

Re: [spring] [Idr] Signalling ERLD (ISIS, OSPF and BGP-LS)

Gunter, I have nothing to add to Les' comments, 100% agree. Cheers, Jeff On 6/13/18, 08:42, "Idr on behalf of Les Ginsberg (ginsberg)" wrote: Gunter - I strongly support Option #2 and strongly support Ketan's recommendation that an MSD sub-type be used to advertise ERLD.

Re: [spring] Updating the SPRING WG Charter

Rob, Sorry for the delay, please see inline. Thanks! Cheers, Jeff From: Rob Shakir Date: Sunday, June 3, 2018 at 14:36 To: Jeff Tantsura Cc: SPRING WG List Subject: Re: [spring] Updating the SPRING WG Charter Hi Jeff, Thanks for the comments. On Fri, Jun 1, 2018 at 9:44

Re: [spring] draft-xu-mpls-sr-over-ip

Loa, I’m not aware of any IPR that applies to this draft. Thanks, Jeff On Thu, Jun 7, 2018 at 06:34 Henderickx, Wim (Nokia - BE/Antwerp) < wim.henderi...@nokia.com> wrote: > I am not aware of IPR related to this draft. > > On 07/06/2018, 03:15, "Loa Andersson" wrote: > > Working Group,

Re: [spring] Updating the SPRING WG Charter

Hi Rob, Looks good, few additions, please see inline Cheers, Jeff From: spring on behalf of Rob Shakir Date: Friday, June 1, 2018 at 09:05 To: SPRING WG List Subject: [spring] Updating the SPRING WG Charter Hi SPRING, After the discussions on the list and in London relating

Re: [spring] IPR Poll for draft-ietf-spring-segment-routing-mpls

Hi Bruno, I'm not aware of any IPR other than that already been disclosed. Thanks! Cheers, Jeff From: spring on behalf of Date: Thursday, May 24, 2018 at 10:28 To: SPRING WG List , "draft-ietf-spring-segment-routing-m...@ietf.org" Subject: [spring] IPR Poll for

Re: [spring] Working Group Adoption Call for draft-filsfils-spring-segment-routing-policy

Yes/support Cheers, Jeff From: spring on behalf of Rob Shakir Date: Wednesday, May 16, 2018 at 17:20 To: SPRING WG List Subject: [spring] Working Group Adoption Call for draft-filsfils-spring-segment-routing-policy Hi

Re: [spring] SPRING - rechartering discussion

Hi, I'm not going to repeat all the valid reasons to continue mentioned beforehand. There's definitely work to be done in architecture and O areas as well as co-ordination of various activities across IETF. Cheers, Jeff On 3/18/18, 13:23, "spring on behalf of Bernier, Daniel"

Re: [spring] Section 9.1 of the draft draft-filsfils-spring-segment-routing-policy (IP/Optical)

the section 9.1 and especially the new SID that we defined is to provide the proper support/context for the POI draft and hence the reference is clear. Cheers, Clarence On 01/03/2018 19:13, Jeff Tantsura wrote: > Hi Ketan, > > Thanks for responding.

Re: [spring] Section 9.1 of the draft draft-filsfils-spring-segment-routing-policy (IP/Optical)

Ketan, Thank you for addressing my comments. Always a pleasure working with you! Cheers, Jeff From: "Ketan Talaulikar (ketant)" <ket...@cisco.com> Date: Friday, March 2, 2018 at 00:39 To: Jeff Tantsura <jefftant.i...@gmail.com>, "draft-filsfils-spring-segm

Re: [spring] Section 9.1 of the draft draft-filsfils-spring-segment-routing-policy (IP/Optical)

and clarifies the intentions. Thanks! Cheers, Jeff From: "Ketan Talaulikar (ketant)" <ket...@cisco.com> Date: Thursday, March 1, 2018 at 09:14 To: Jeff Tantsura <jefftant.i...@gmail.com>, "draft-filsfils-spring-segment-routing-pol...@ietf.org" <draft-filsfils-spr

[spring] Section 9.1 of the draft (IP/Optical)

Hello authors of draft-filsfils-spring-segment-routing-policy(further references as policy draft), We, authors of draft-anand-spring-poi-sr draft(further referenced as poi draft) have noted that section 9.1 of 04 version of the policy draft now has IP/Optical use case, that is in great

Re: [spring] New spring WG Co-Chair

Martin – thank you for the great work and congratulations! Rob – welcome, grand to see you coming in, looking forward to continuing our great  and fruitful cooperation! Jeff From: spring on behalf of Alvaro Retana Date: Wednesday, 21

Re: [spring] [OSPF] [Idr] A comment regarding the relationship between RLD and ERLD

Gunter, As I also said in Singapore - another interesting use case would be related to statistics, without going into semantics, we might need another SID in the stack to uniquely identify a tunnel (domain wide)that would result in a counter hit. RLD is crucial here. There would be some

Re: [spring] [mpls] working group last call on draft-ietf-mpls-spring-entropy-label

Loa, Support as co-author. Thanks! Cheers, Jeff -Original Message- From: mpls on behalf of Loa Andersson Date: Friday, December 8, 2017 at 05:17 To: "m...@ietf.org" Cc: "spring@ietf.org" , "mpls-cha...@ietf.org"

Re: [spring] [mpls] Special purpose labels in draft-hegde-spring-traffic-accounting-for-sr-paths

Wrt architecture - don’t think one has to fit all needs. While some migrate to SR from IP/LDP environment and pretty happy with what they have got today, others come from a heavy traffic engineered one, with per LSP/node counters that are mandatory from a network management prospective(and I

Re: [spring] [mpls] Special purpose labels in draft-hegde-spring-traffic-accounting-for-sr-paths

Hi, Some comments after reading the thread: /*rtgwg-chair hat on I wonder, who are the mighty “we” who are better than unworthy “them”?  I find the wording rather unfortunate */ The problem statement – Uniquely identify at any given node: (SID stack, *) or (*, source) or (SID

Re: [spring] [mpls] Special purpose labels in draft-hegde-spring-traffic-accounting-for-sr-paths

huawei.com 产品与解决方案-网络战略与业务发展部 Products & Solutions-Network Strategy & Business Development Dept 发件人： Jeff Tantsura 收件人： Robert Raszuk<rob...@raszuk.net> 抄送： Xuxiaohu<xuxia...@huawei.com>;Greg Mirsky<gregimir...@gmail.com>;spring<spring@ietf.org>;mpls<m...@ietf.org

Re: [spring] [mpls] Special purpose labels in draft-hegde-spring-traffic-accounting-for-sr-paths

path so what is the problem ? thx r. On Nov 16, 2017 10:47, "Jeff Tantsura" <jefftant.i...@gmail.com> wrote: Robert, HW counters are rather precious resources, but that’s beside the point. An architecture is not an immutable object, on contrary, a very import pr

Re: [spring] [mpls] Special purpose labels in draft-hegde-spring-traffic-accounting-for-sr-paths

Robert, HW counters are rather precious resources, but that’s beside the point. An architecture is not an immutable object, on contrary, a very import property of a good architecture is flexibility and agility, ability to adapt when business need arises.   Keeping semantics aside –

Re: [spring] FW: New Version Notification for draft-clad-spring-segment-routing-service-chaining-00.txt

question, whether you think Informational track would be more appropriate. Thanks! Cheers, Jeff -Original Message- From: "Bernier, Daniel" <daniel.bern...@bell.ca> Date: Tuesday, October 24, 2017 at 09:35 To: Jeff Tantsura <jefftant.i...@gmail.com>, "

Re: [spring] FW: New Version Notification for draft-clad-spring-segment-routing-service-chaining-00.txt

Hi Francois, The draft has been published as the Standards Track document. What is it you have been trying to standardize? Thanks! Cheers, Jeff -Original Message- From: spring on behalf of "Francois Clad (fclad)" Date: Wednesday, October

Re: [spring] WG Last Call for draft-ietf-spring-conflict-resolution

Yes/support On Mon, Jul 10, 2017 at 23:00 wrote: > Hello Martin, > I support the draft as co-author. I am not aware of any relevant IPR. > Thanks, > Martin > > On 07/10/2017 02:58 PM, Martin Vigoureux wrote: > > WG, > > > > We are half-way through the WG Last Call and I am

Re: [spring] [OSPF] OSPFv2 Segment Routing Extensions ERO Extensions (would also effect OSPFv3 and IS-IS) - REPLY TO THIS ONE

Hi, I have got pretty much same view as Acee. There are many application (future, to my knowledge no products) for which the concept of Binding SID (anchor node) is central, I’m aware of ISIS implementation, didn’t see OSPF. Currently, I don’t see any use to ERO extensions, perhaps could be

Re: [spring] A belated comment on end-to-end path protection in draft-ietf-spring-resiliency-use-cases

resending with reduced number of recipients. Cheers, Jeff Sasha, Don’t forget – RSVP-TE FRR has explicit signaling and state associated with it, as well as well defined state transitions, SR on contrary doesn’t. Changes in topology (link/node down events) are not communicated back

Re: [spring] Is MSD really a configurable attribute?

at 22:28 To: Alexander Vainshtein <alexander.vainsht...@ecitele.com> Cc: Jeff Tantsura <jefftant.i...@gmail.com>, "spring@ietf.org" <spring@ietf.org>, Shell Nakash <shell.nak...@ecitele.com>, Michael Gorokhovsky <michael.gorokhov...@ecitele.com>, Ron S

Re: [spring] Is MSD really a configurable attribute?

shtein <alexander.vainsht...@ecitele.com> Cc: Jeff Tantsura <jefftant.i...@gmail.com>, "spring@ietf.org" <spring@ietf.org>, Shell Nakash <shell.nak...@ecitele.com>, Michael Gorokhovsky <michael.gorokhov...@ecitele.com>, Ron Sdayoor <ron.sday...@ecitele.com>, Rotem

Re: [spring] Is MSD really a configurable attribute?

Hi Muthu, Thanks for your comments! MSD is a configurable attribute, it is not derived directly from HW capabilities, in fact no vendor today provides an API to query underlying HW for the MSD supported, there’s also dependency on SW support. That’s why we have introduced “Type” field,

Re: [spring] IDR WG 2 week WG LC on draft-ietf-idr-bgpls-segment-routing-epe - (2/15/2017 to 3/1/2017)

Yes/support Regards, Jeff > On Feb 15, 2017, at 23:34, Susan Hares wrote: > > This begins a 2 week IDR WG last call on > draft-ietf-idr-bgpls-segment-routing-epe from (2/15 to 3/1/2017)There are > two implementations describe on the wiki at: >

Re: [spring] WG Last Call for draft-ietf-spring-segment-routing-central-epe

yes/support Cheers, Jeff From: spring on behalf of Date: Monday, February 13, 2017 at 02:08 To: "spring@ietf.org" Subject: [spring] WG Last Call for draft-ietf-spring-segment-routing-central-epe Hello

Re: [spring] WG LC for draft-ietf-spring-segment-routing

As contributor I support the submission of this document to the IESG as a Proposed Standard. Cheers, Jeff On 11/28/16, 01:37, "spring on behalf of Martin Vigoureux" wrote: Hello WG, this e-mail initiates a

Re: [spring] SID Conflict Resolution: A Simpler Proposal

+1 Cheers, Jeff From: spring on behalf of "Acee Lindem (acee)" Date: Monday, December 5, 2016 at 08:28 To: "Les Ginsberg (ginsberg)" , "spring@ietf.org" Subject: Re: [spring] SID Conflict Resolution:

Re: [spring] meaning of "Strict Shortest Path" algorithm in draft-ietf-spring-segment-routing-09

te: Hi Jeff, > On Sep 22, 2016, at 4:47 PM, Jeff Tantsura <jefftant.i...@gmail.com> wrote: > > Hi Stefano, > > Thanks for the explanation, I have got a bit of different view on the use of algorithm logic. > PBR is orthogonal to what

Re: [spring] meaning of "Strict Shortest Path" algorithm in draft-ietf-spring-segment-routing-09

ailto:sprev...@cisco.com] > Sent: Monday, September 19, 2016 4:17 PM > To: Alexander Vainshtein <alexander.vainsht...@ecitele.com>; Jeff Tantsura <jefftant.i...@gmail.com>; Chris Bowers <cbow...@juniper.net> > Cc: spring@ietf.org > Subject: Re: [spring] meanin

Re: [spring] WG adoption requested for draft-filsfils-spring-sr-recursing-info

Yes/support On Sun, Jul 24, 2016 at 5:54 AM John G. Scudder wrote: > Dear WG, > > As we discussed at our meeting, working group adoption has been requested > for draft-filsfils-spring-sr-recursing-info. Please reply to the list with > your comments, including although not

Re: [spring] WG adoption requested for draft‐filsfils‐spring‐large-scale-interconnect

Support as co-author not aware of any relevant IPR that has not been previously disclosed. Cheers, Jeff On Sun, Jul 24, 2016 at 6:10 AM Henderickx, Wim (Nokia - BE) < wim.henderi...@nokia.com> wrote: > As a co-author is support WG adoption. > Not aware of IPR related to this draft > > > > > On

Re: [spring] IPR for draft-ietf-spring-segment-routing prior to (additional) WGLC

John, I’m not aware of any relevant IPR that has not been previously disclosed. Cheers, Jeff On Sun, Jul 24, 2016 at 6:15 AM Henderickx, Wim (Nokia - BE) < wim.henderi...@nokia.com> wrote: > As a contributor not aware of IPR related to this draft > > > > > On 24/07/16 14:49, "spring on behalf

Re: [spring] draft-ginsberg-spring-conflict-resolution - IPR Call

Same here On 4/14/16, 12:49 AM, "spring on behalf of Henderickx, Wim (Nokia - BE)" wrote: >As reviewer not aware on IPR related to this draft > > > > >On 13/04/16 20:32, "spring on behalf of EXT Martin Pilka"

Re: [spring] draft-ginsberg-spring-conflict-resolution: SRGB INCONSISTENCY

Pragmatic and working approach, I support it. Cheers, Jeff From: spring > on behalf of "Les Ginsberg (ginsberg)" > Date: Tuesday, January 12, 2016 at 13:06 To:

Re: [spring] working group adoption call for draft-filsfils-spring-segment-routing-ldp-interop

Yes/support Cheers, Jeff -Original Message- From: Rob Shakir Date: Friday, September 4, 2015 at 4:12 PM To: "John G.Scudder" , "spring@ietf.org" Subject: Re: [spring] working group adoption call for

  1   2   >