Hi,
Speaking as a big user of OL bit for ops and design purpose, yes CSPF needs to
take it into account.
Brgds,
From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Girish Pattanaik
Sent: Wednesday, December 19, 2018 19:12
To: spring@ietf.org
Cc: Girish Pattanaik
Subject: [spring] Will
As mentioned, you could not be aware of all the constraints that we have and
BGP 3107 is not an option.
Note that this kind of redistribution can even happen within a single AS. We
had some OSPF domain prefixes leaked in the ISIS L2 in the past in a single AS.
Nothing prevents this design to
We can’t for some internal design/security reasons.
From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of ???(??)
Sent: Tuesday, November 20, 2018 09:10
To: spring; Lsr; l...@ietf.org
Cc: spring@ietf.org
Subject: Re: [Lsr] [spring] draft-ietf-isis-mpls-elc & draft-ietf-ospf-mpls-elc
Why not
Hi all,
The use case is without TE. And this is how network designs are working today,
and I do not see any valid reason to complexify and change the existing designs
by introducing controllers or BGP-LS.
We have to accommodate with what is deployed today and the proposed change is
quite
Hi WG,
Some discussions occurred on the mailing list on how to encode the entropy
label capability for SR but we hadn't found a consensus on the target solution.
IETF 103 was the opportunity to meet face to face various people that have
participated to this discussion.
Following this
Hi Sasha,
Could you elaborate on :" I strongly suspect that it is not so, and that these
mechanisms are only compatible with the Strict-SPF. (Actually, I can provide an
example that confirms this suspicion.)" ?
Thanks,
From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Alexander
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
Hi,
I'm not aware of any IPR
From: bruno.decra...@orange.com [mailto:bruno.decra...@orange.com]
Sent: Thursday, May 24, 2018 19:28
To: SPRING WG List; draft-ietf-spring-segment-routing-m...@ietf.org
Subject: IPR Poll for draft-ietf-spring-segment-routing-mpls
Hi SPRING WG,
In parallel to the
Support
Not aware of any IPR
From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Rob Shakir
Sent: Wednesday, May 16, 2018 17:20
To: SPRING WG List
Subject: [spring] Working Group Adoption Call for
draft-filsfils-spring-segment-routing-policy
Hi SPRING WG,
This email initiates a two
Hi Daniel,
You may need to introduce new hardware as well for SRTE to handle the number of
labels to push.
If your hardware is flexible (network processors), there is a chance that it
can also handle NSH.
Now if you want just to use SR policies to perform a kind of service chaining,
is there
For simple service chains, policy routing works fine as well (this was what was
used before bess-service-chaining has come). It becomes a nightmare when the
service chains are complex.
From: Henderickx, Wim (Nokia - BE/Antwerp) [mailto:wim.henderi...@nokia.com]
Sent: Tuesday, March 20, 2018
> Same approach that IETF took for EVPN with various encap options like MPLS,
> VXLAN, GENEVE,..
Well you do have the same thing with SFC/NSH, you can use any type of transport
underneath: MPLS, VXLAN, GRE,UDP,…
In your example EVPN provides the service, then you pick the transport you want.
Hi,
I’m worrying that MPLS based SFCs may slowdown implementations of NSH.
Vendors have usually a limited bandwidth to implement new features especially
when the dataplane is involved. I would personally prefer to get the resources
allocated to NSH rather than MPLS based SFCs.
This is not just
Hi Les,
I think there is a fundamental disagreement here.
"SR Global Block (SRGB): local property of an SR node. In the MPLS
architecture, SRGB is the set of local labels reserved for global
segments."
We agree that the SRGB is a per node property, but a per node+per protocol SRGB
is
Hi,
In the current version of the draft, conflict evaluation does not look at the
SRGB, it only looks at SIDs.
In any case, in the given example, there is a prefix conflict => multiple
SIDs/labels associated to a single prefix.
>From an LFIB point of view, as per the current draft, only a
Hi,
I think there is a misunderstanding on what the text says:
“ A first protection strategy consists in excluding any local repair
but instead use end-to-end path protection where each SPRING path is
protected by a second disjoint SPRING path. In this case local
protection MUST NOT be
Hi Stefano,
Speaking as doc Shepherd, I do not see in the V09, how you are addressing Lou's
point about 1:1 and 1+1 protection in the Section 2.
I think it make sense to add a simple explicit statement that SPRING should
support both approach. It is partially addressed by " The two paths may
Support
-Original Message-
From: Martin Vigoureux [mailto:martin.vigour...@nokia.com]
Sent: Friday, January 27, 2017 12:05
To: spring@ietf.org
Cc: draft-ietf-spring-segment-routing-m...@ietf.org
Subject: WG Last Call for draft-ietf-spring-segment-routing-mpls-06
Hello Working Group,
Hi,
As Stefano mentioned, as it's a use case and requirement draft, we do not have
to talk about solutions, and about issues in using one or other mechanism.
Such considerations about using or not some particular SIDs to fill the "path
must not be protected by any local repair" constraint are
Hi Authors,
Could you please check the comment's below so we can continue to progress the
document ?
Thanks !
From: spring [mailto:spring-boun...@ietf.org] On Behalf Of
stephane.litkow...@orange.com
Sent: Monday, August 22, 2016 15:14
To: draft-ietf-spring-resiliency-use-ca...@ietf.org
Cc:
Hi Les,
Administrative distance (protocol preference) has always been used in router
implementation for a while. Yes inconsistent configuration of admin distance
can cause routing issues (loops or whatever ...). I'm not sure we can really
bypass it ...
Regarding the preference algorithm, the
+1
-Original Message-
From: spring [mailto:spring-boun...@ietf.org] On Behalf Of
bruno.decra...@orange.com
Sent: Thursday, April 14, 2016 09:51
To: spring@ietf.org
Subject: [spring] draft-ginsberg-spring-conflict-resolution - WG adoption call
Dear WG,
As we discussed at our meeting
Hi Les,
BGP needs also to be taken into account : draft-ietf-idr-bgp-prefix-sid.
IMO, as I already pointed, it would be easier to handle it a single document
rather than in the protocol docs. Moreover we will have the sender part in many
docs, and the receiver part in the
[Les:] Just to be sure I understand you, you are advocating putting the SRGB
sender behavior specification in draft-ginsberg-spring-conflict-resolution as
well as the receiver behavior?
Sender behavior HAS to be specified in the protocol documents as it describes
the normative behavior of the
Hi Stefano,
My worry is that tomorrow we will have a new protocol, and this KEY piece may
be forgotten because nothing tells that this is required... and this is a cross
protocol behavior that we want.
I'm fine to have it in the protocol as far as we have a more global document
telling that
Fully agree but this is not the choice that has been made at the beginning. Do
you want to propose a change ?
From: rras...@gmail.com [mailto:rras...@gmail.com] On Behalf Of Robert Raszuk
Sent: Friday, January 08, 2016 15:26
To: LITKOWSKI Stephane SCE/OINIS
Cc: Stewart Bryant; Les Ginsberg
Hi Les,
Yes we come back to the Yang discussion :)
I think the text you pointed is no more valid, as the consensus was to
authorize per protocol configuration as a feature. I think we missed to update
this definition part when we updated the model.
Here is the augmentation for ISIS :
augment
Hi Robert,
Regarding SRGB management, it’s really a design choice. There was already some
discussion in the past.
If people/implementations uses a global SRGB which is agnostic to protocols,
cross protocol validation does not really make sense.
If people/implementations uses per protocol SRGB,
Why not ... but in this case why also having Node-SID bound to a prefix ? Today
Anycast and Node-SID are all a subcase of the IGP Prefix SID, so bound to a
prefix.
I agree that there is no real need to bind them to a prefix as long as we can
still compute the path towards the SID (now we
Hi Les,
Happy new year.
I agree with your proposal.
The text must state that there must be a local configuration mechanism that
avoids sender to originate overlapping SRGB.
In this case, as you mention, if a router receives overlapping SRGB, this is a
bad behavior and we cannot guess if the
Hi Les,
I completely agree that consensus is not achieved yet, no worry. The only
consensus we have is on per IGP instance SRGB support.
But as the discussion moved to encoding issue, I just wanted to highlight that
it may not be an issue.
Anyway, yes, we need to find a consensus.
Best
Hi,
Just to know, is there some implementation today supporting MT for SPRING ? The
other point is : if yes, does someone use it in a live network ? If no, there
is no issue to change.
I agree that a migration is not easy, but coming back to previous sentence,
honestly I think no one use MT
Hi Peter,
There are some mix between SIDs and labels in your text.
Some comments inline
-Original Message-
From: Peter Psenak [mailto:ppse...@cisco.com]
Sent: Wednesday, August 26, 2015 10:43
To: LITKOWSKI Stephane SCE/IBNF; Eric C Rosen; Pushpasis Sarkar; SPRING WG
Subject: Re:
Hi Peter,
1. If a new topology is added by use of the MT features of an IGP,
then a new set of prefix-SIDs must be provisioned. This seems like a
major provisioning task. The alternative would be to have an SRGB per
topology; then when you add a new topology, you only have one quantity
Hi Stefano,
The new text for anycast fits perfectly my previous comment.
Best Regards,
-Original Message-
From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Stefano Previdi
(sprevidi)
Sent: Friday, July 31, 2015 09:55
To: spring@ietf.org
Subject: [spring] Fwd: New Version
Looks that consensus is for option#2, so let's move SRGB to protocol
configuration.
From: Jeff Tantsura [mailto:jeff.tants...@ericsson.com]
Sent: Friday, July 31, 2015 08:04
To: LITKOWSKI Stephane SCE/IBNF; spring@ietf.org
Subject: Re: [spring] Modeling SRGB configuration for
Hi all,
What if we keep the SRGB block config in segment-routing global module, and
if we allow for YANG configuration of carving this block inside each protocol
(maybe as a feature) ?
Stephane
From: Uma Chunduri [mailto:uma.chund...@ericsson.com]
Sent: Friday, July 24, 2015 16:59
To: Les
Hi Chairs,
I currently have some issue with the anycast section of the draft. Based on the
discussion we had during the WG session (through Pushpasis's presentation), it
looks that the anycast section is not enough explained (what is the problem
behind ...) and using a MUST for mandating
Support, not aware of any IPR
-Original Message-
From: mpls [mailto:mpls-boun...@ietf.org] On Behalf Of John G.Scudder
Sent: Wednesday, July 22, 2015 15:17
To: spring@ietf.org
Cc: m...@ietf.org
Subject: [mpls] working group adoption call for
Hi WG,
In the current version of the config Yang model for SR, the SRGB list is
configured at SR top level, so it is agnostic to the routing protocol.
We had some comment in Dallas on difficulties that having common label range
shared between protocols could lead to.
During discussion in our
Hi Tarek,
I think per-prefix granularity is still possible.
Advertising a SRGB for a particular algorithm does not mean that all the
prefixes advertised will be advertised for that particular algorithm.
I mean considering you have a network with node A ,B, C, D, each one
advertising a
Hi Uma,
Pls find inline comments.
-Original Message-
From: Uma Chunduri [mailto:uma.chund...@ericsson.com]
Sent: Tuesday, June 30, 2015 20:24
To: Aissaoui, Mustapha (Mustapha); DECRAENE Bruno IMT/OLN
Cc: LITKOWSKI Stephane SCE/IBNF; spring@ietf.org; isis...@ietf.org list;
Stefano
Hi Bruno,
Support as author and I'm not aware of any IPR on this document
-Original Message-
From: spring [mailto:spring-boun...@ietf.org] On Behalf Of
bruno.decra...@orange.com
Sent: Monday, June 29, 2015 19:22
To: spring@ietf.org
Subject: [spring] Poll for adoption:
Hi Bruno,
It would be good if we can have 10min to present the progress on SPRING Yang
model.
Thanks,
Stephane
-Original Message-
From: spring [mailto:spring-boun...@ietf.org] On Behalf Of
bruno.decra...@orange.com
Sent: Monday, June 22, 2015 20:41
To: spring@ietf.org
Subject:
Support.
I'm not aware of any IPR on this document.
From: spring [mailto:spring-boun...@ietf.org] On Behalf Of
bruno.decra...@orange.com
Sent: Wednesday, June 10, 2015 17:06
To: spring@ietf.org
Subject: [spring] Poll for adoption: draft-kumar-spring-sr-oam-requirement
Hello working group,
Even if choosing any IP to MPLS entry does not break anything, I'm not sure
this is a good idea from an operational point of view to let it undeterministic.
-Original Message-
From: spring [mailto:spring-boun...@ietf.org] On Behalf Of
bruno.decra...@orange.com
Sent: Thursday, June 18,
Hi Bruno,
1) I don't really the issue. From a forwarding standpoint, looks like
we can simply program multiple SIDs in the FIB.
[SLI] What about the IP to MPLS entry ?
I think it would be good to discuss this topic within SPRING WG.
-Original Message-
From: OSPF [mailto:ospf-boun...@ietf.org] On Behalf Of
stephane.litkow...@orange.com
Sent: Monday, January 12, 2015 09:14
To: Rob Shakir
Cc: isis...@ietf.org;
I'm not aware of non disclosed IPR.
-Original Message-
From: spring [mailto:spring-boun...@ietf.org] On Behalf Of
bruno.decra...@orange.com
Sent: Wednesday, November 12, 2014 19:40
To: Alvaro Retana (aretana)
Cc: spring@ietf.org; draft-filsfils-spring-segment-routing-m...@tools.ietf.org
I'm not aware of non disclosed IPR.
From: Alvaro Retana (aretana) [mailto:aret...@cisco.com]
Sent: Wednesday, September 24, 2014 15:03
To: draft-filsfils-spring-segment-rout...@tools.ietf.org
Cc: spring@ietf.org
Subject: IPR Claims related to draft-filsfils-spring-segment-routing
Hi!
In
IMHO,
1) is ECMP needed with MPLS SPRING (in particular, Adj-SID)?
Yes it is ... SPRING brings more flexibility in ECMP for TE tunnels than
RSVP-TE does. And ECMP with Bundle-Adj-SID is something really useful when a
Service Provider is using parallel ECMP links rather than LAGs.
2) is EL the
We already know how to encode label offset.
Are you referring to Segment Index as offset of label base ?
Using the same encoding you can treat offset value as number of significant
bits within the 20 bit label.
Could you give an example of lookup and forwarding structure for your label
52 matches
Mail list logo
