Re: [spring] Updating the SPRING WG Charter

Hi Zafar, As mentioned in my previous mail, the VPN+ drafts and this work item require new functionality to be added to SR, which is to associate SR with particular allocated resources and treatment. IMO this is not covered by existing SR mechanisms. It is different from Diffserv QoS, and it

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

Hi, As defined in draft-ietf-mpls-spring-entropy-label, advertising an ERLD means that the node is defacto ELC (so advertising ELC separately is not necessary): " The Entropy Readable Label Depth (ERLD) is defined as the number of labels a router can both: a. Read in an MPLS packet

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] [mpls] draft-xu-mpls-sr-over-ip

I'm not aware of any IPR. Yours Irrespectively, John > -Original Message- > From: mpls On Behalf Of Loa Andersson > Sent: Thursday, June 7, 2018 6:15 AM > To: m...@ietf.org > Cc: spring@ietf.org; mpls-cha...@ietf.org; draft-xu-mpls-sr-over...@ietf.org > Subject: [mpls]

[spring] FW: I-D Action: draft-farrel-spring-sr-domain-interconnect-04.txt

Some of you may recall discussing this in SPRING a few meetings ago. It is an overview of how a number of networking building blocks fit together to provide interconnection of SR domains. There is no new technology defined in the document: just a high-level view of how mechanisms defined in

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

Gunter - I strongly support Option #2 and strongly support Ketan's recommendation that an MSD sub-type be used to advertise ERLD. This is the unified framework that the MSD advertisement has been designed to support. The following documents provide a unified definition of this mechanism:

Re: [spring] Updating the SPRING WG Charter

Hi Bruno, I am aware of the VPN+ draft but IMO this document or Slicing, in general, is an informational use-case document (E.g., similarly SD-WAN does not have a milestone in the Charter). I do not think that there is any new behavior needed beyond SRTE, SRVPN, Flex-Algo, Diffserv QoS and SR

Re: [spring] RtgDir review: draft-ietf-spring-segment-routing-ldp-interop-11

Hi I just published version 13 https://www.ietf.org/internet-drafts/draft-ietf-spring-segment-routing-ldp-interop-13.txt I moved the section about migration to appendix Thanks Ahmed On 5/26/18 8:47 AM, Tomonori Takeda wrote: Hello, I have been selected as the Routing Directorate reviewer

[spring] Is TI-LFA compatible with the default SR algorithm?

Hi all, I have looked up Section 3.1.1 "Prefix-SID Algorithm" of the Segment Routing Architecture draft (already In the RFC Editor queue) and found there the following statement (the relevant part is highlighted): This document

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

I am not aware of any IPR related to this draft Regards Luay On Thu, Jun 7, 2018, 5:15 AM Loa Andersson wrote: > Working Group, > > We are currently preparing draft draft-xu-mpls-sr-over-ip for working > group adoption. > > Part of this preparation is to do an IPR poll. > > This mail is to

Re: [spring] Updating the SPRING WG Charter

Dear Ji, you’ve written „Although SR can rely on the network controller for global traffic optimization and placement, there is no mechanism to provide resource guarantee and service separation in the data plane.” If this is linked to maintenance of per segment (or per segment range) state on

Re: [spring] Updating the SPRING WG Charter

Dear Zafar, As Bruno and Sasha have pointed out, the enhanced VPN drafts are relevant to this work item. As mentioned in one of my previous email (the pointer is also provided in Bruno’s mail), currently SR is mainly designed for source routing based path steering, comparing to RSVP-TE, it

Re: [spring] WG Last Call for draft-ietf-spring-segment-routing-mpls-14

Dear authors, I've read the document and have one minor comment and 3 editorials/nits, see below. As a general comment from a non-native speaker I'd suggest a review by a native speaker (noting that one of the authors is a native speaker). I went through that with some of the informational

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

It is desirable that same understanding of TLVs ([ELC, RLD] or [ERLD]) are signaled for ISIS, OSPF and BGP-LS. If the WG's can manage to agree upon a decision (option1/2/3 or 4), then next, have a look into how to encode the TLV so that we have a clean technological solution space. G/

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

Indeed, the debate that made BGP-LS to go down the ERLD path is of pragmatic motivation. The major Readable Label Depth use-case is entropy. Hence, if the ERLD TLV is available, then ELC can be implicitly assumed. No pragmatic reason to signal separately, as it just make things more complex

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

Hi Loa, I am not aware of any IPR related to this document. Best regards, Mach > -Original Message- > From: mpls [mailto:mpls-boun...@ietf.org] On Behalf Of Loa Andersson > Sent: Thursday, June 07, 2018 6:15 PM > To: m...@ietf.org > Cc: spring@ietf.org; mpls-cha...@ietf.org;

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

Hi Loa, I am not aware of any IPR related to this draft. Best regards, Gunter Van de Velde -Original Message- From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Loa Andersson Sent: Thursday, June 7, 2018 12:15 To: m...@ietf.org Cc: spring@ietf.org; mpls-cha...@ietf.org;

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

Hi Loa I'm not aware of any IPR that applies to this draft. Thanks, Luis __ Luis M. Contreras Technology and Planning Transport, IP and Interconnection Networks Telefónica I+D / Global CTIO unit / Telefónica Distrito Telefónica, Edificio Sur 3, Planta 3 28050

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

Hi Gunter, The difference in IGP signalling seems to be because the ELC is a capability which is advertised differently than ERLD which is a limit. Are you saying that ELC does not have value by itself without the ERLD? IMHO it makes sense to retain ELC as capability of the router (as