[Lsr] Request slot for LSR@101 - draft-eckert-teas-bier-te-framework
Dear LSR WG chairs, I am hereby requesting a slot for LSR WG @IETF101 to present subject draft. At the core of the proposed framework for the control plane of BIER-TE is a proposed topology model for BIER-TE to allow path calculation (and other consistency calculation) - distributed through the IGPs. I would like to get early feedback before we would start to work on the actual encoding of this topology information into IGP LSA/LSP types. Cheers Toerless ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] Request slot for LSR@101 - draft-eckert-teas-bier-te-framework
Thanks, Acee - too bad. Very much a fan of creation of LSR. Sad that it meant moving from two underused WG meetings to one WG meeting that does not have enough time for new work. Reminds me of TSVWG. *sigh* Well, i guess all i am left with is to ask LSR WG members to attend TEAS on monday and hope my request for slot there will be successful. Feedback on the proposed topology model is important for the design. Cheers Toerless P.S.: When are requests for slots LSR@IEF102 opening up ? ;-)) On Tue, Mar 06, 2018 at 10:44:44PM +, Acee Lindem (acee) wrote: > Hi Toerless, > > Unfortunately, we have a very full agenda already and are not taking > additional presentation for IETF 101. Additionally, you're going to need to > present it in TEAS anyway due to their mandate... > > Thanks, > Acee > > ???On 3/6/18, 4:56 PM, "Lsr on behalf of Toerless Eckert" > <lsr-boun...@ietf.org on behalf of t...@cs.fau.de> wrote: > > Dear LSR WG chairs, > > I am hereby requesting a slot for LSR WG @IETF101 to present subject > draft. > > At the core of the proposed framework for the control plane of BIER-TE is > a proposed topology model for BIER-TE to allow path calculation (and other > consistency calculation) - distributed through the IGPs. > > I would like to get early feedback before we would start to work on the > actual encoding of this topology information into IGP LSA/LSP types. > > Cheers > Toerless > > ___ > Lsr mailing list > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr > ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] LSR: Using DSCP for path/topology selection Q
On Fri, Nov 16, 2018 at 12:28:27AM +0100, Robert Raszuk wrote: > Hey Toerless, > > Please observe that DSCP based steering may be very useful vehicle for end > hosts/applications influencing how their packets are transported. > > So instead of closing that option I recommend we at least take a good look > at what alternative mechanism exists. I think back when DSCP was selected for MTR in implementations, it was done so due to the absence of better options. But as i mentioned, the overloading of DSCP between QoS and routing made it (in my memory) undesirable to operators. And when designing new solutions with new QoS like in DetNet its yet a similar possible problem. If we hopefully do not need to find solutions for IPv4, i would rather like to see something like what SR did, e.g.: IPv6 header extension. These are AFAIK now also easily settable from linux programs (ok., maybe not yet from javascript). Or much easier of course the existing IPv6 multi-addressing solutions where hosts can also lern semntics of these addresses. And map to diffeent flex-topologies instead of just multi-homing exit points (which i think was the main use-case so far). > And btw I read Peter's note as possibility (or invitation) to define > algorithm which takes into account DSCP rather then a announcement that > this is not there and it should never be. Sure, i am only talking about the solutions that tried to use DSCP for routing so far. I think those failed. And when other agree and we codify that, then that would not exclude the option for new work (like what Peter may have in mind) to superceed that recommendation. Cheers Toerless > Cheers, > R. > > > > On Fri, Nov 16, 2018 at 12:22 AM Toerless Eckert wrote: > > > > > Thanks, Les, Peter > > > > So... is there any opinion about creating a normative or BCP > > recommendation to > > not use DSCP to distinguish topologies/flex-algos ? Mabybe this would > > not be appropriate for LSR, but TSVWG, but i think it would be > > participants in LSR that would know if there is actually still any > > customer demand for this option. > > > > Cheers > > Toerless > > > > P.S.: Context of the email is DetNet trying to define what a DetNet flow > > is and currently this includes the thinking that DetNet flows could be > > 6-tuple flows including DSCP because different DSCP could be routed > > differently in the network via MTR, and that concept IMHO would just > > result in making a foal (DetNet) a lot more complex because of a dead > > horse (DSCP MTR). > > > > On Thu, Nov 15, 2018 at 04:41:06AM +, Les Ginsberg (ginsberg) wrote: > > > Toerless - > > > > > > It's pretty hard to understand the context for your email. > > > > > > What leads you to believe that any of the MT specifications you mention > > say anything normative about DSCP and topologies?? > > > > > > RFC4915 does not mention DSCP at all - but does make the statement: > > > > > > https://tools.ietf.org/html/rfc4915#section-3.8 > > > "It is outside of the scope of this document to specify how the > > >information in various topology specific forwarding structures are > > >used during packet forwarding or how incoming packets are associated > > >with the corresponding topology." > > > > > > RFC 5120 does mention DSCP, but only as an example of something that > > "could" be used to determine on what topology a packet should be forwarded. > > > > > > RFC 7722 also mentions DSCP as an example, but there is a statement in > > Section 3: > > > > > > "It is assumed, but > > >outside the scope of this specification, that the network layer is > > >able to choose which topology to use for each packet" > > > > > > IGP WGs have never attempted to recommend (let alone normatively define) > > any relationship between DSCP and MT. > > > > > > ??? > > > > > >Les > > > > > > > -Original Message- > > > > From: Lsr On Behalf Of Toerless Eckert > > > > Sent: Wednesday, November 14, 2018 6:29 PM > > > > To: lsr@ietf.org > > > > Subject: [Lsr] LSR: Using DSCP for path/topology selection Q > > > > > > > > Whats the current best guidance on using DSCP for selection of path, > > > > specifically for selection of topology with MTR (RFCs 4915, 5120, > > 7722) ? > > > > > > > > My understanding from history is that this looked like a good idea > > > > to customers first, but when impleme
Re: [Lsr] LSR: Using DSCP for path/topology selection Q
Thanks, Les, Peter So... is there any opinion about creating a normative or BCP recommendation to not use DSCP to distinguish topologies/flex-algos ? Mabybe this would not be appropriate for LSR, but TSVWG, but i think it would be participants in LSR that would know if there is actually still any customer demand for this option. Cheers Toerless P.S.: Context of the email is DetNet trying to define what a DetNet flow is and currently this includes the thinking that DetNet flows could be 6-tuple flows including DSCP because different DSCP could be routed differently in the network via MTR, and that concept IMHO would just result in making a foal (DetNet) a lot more complex because of a dead horse (DSCP MTR). On Thu, Nov 15, 2018 at 04:41:06AM +, Les Ginsberg (ginsberg) wrote: > Toerless - > > It's pretty hard to understand the context for your email. > > What leads you to believe that any of the MT specifications you mention say > anything normative about DSCP and topologies?? > > RFC4915 does not mention DSCP at all - but does make the statement: > > https://tools.ietf.org/html/rfc4915#section-3.8 > "It is outside of the scope of this document to specify how the >information in various topology specific forwarding structures are >used during packet forwarding or how incoming packets are associated >with the corresponding topology." > > RFC 5120 does mention DSCP, but only as an example of something that "could" > be used to determine on what topology a packet should be forwarded. > > RFC 7722 also mentions DSCP as an example, but there is a statement in > Section 3: > > "It is assumed, but >outside the scope of this specification, that the network layer is >able to choose which topology to use for each packet" > > IGP WGs have never attempted to recommend (let alone normatively define) any > relationship between DSCP and MT. > > ??? > >Les > > > -Original Message- > > From: Lsr On Behalf Of Toerless Eckert > > Sent: Wednesday, November 14, 2018 6:29 PM > > To: lsr@ietf.org > > Subject: [Lsr] LSR: Using DSCP for path/topology selection Q > > > > Whats the current best guidance on using DSCP for selection of path, > > specifically for selection of topology with MTR (RFCs 4915, 5120, 7722) ? > > > > My understanding from history is that this looked like a good idea > > to customers first, but when implementations became available, > > customers really did not want to implement it because of the overloading > > of DSCP between QoS and routing and the resulting management > > complexity. > > > > Has the idea of using DSCP for path selection been re-introduced in any > > later work like flex-Algos ? > > > > If there could be rough consensus that this is in general a bad idea, i > > wonder > > if it would be appropriate to have a short normative document from LSR > > defining that the use of DSCP for topology selection is historic and > > not recommended anymore and make this an update to above three RFCs, > > maybe also pointing out that there are other methods to select a > > topology and those remain viable: > > > > I specifically would not like to see the actual MTR RFCs to be changed > > in status, because MTR actually does work quite well and is supported > > in products and deployed with IP multicast, even with multiple > > topologies for IP multicast in live-live scenarios. > > > > Thanks! > > Toerless > > > > ___ > > Lsr mailing list > > Lsr@ietf.org > > https://www.ietf.org/mailman/listinfo/lsr > > ___ > Lsr mailing list > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr -- --- t...@cs.fau.de ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] LSR: Using DSCP for path/topology selection Q
On Fri, Nov 16, 2018 at 12:14:45AM -0800, Jeff Tantsura wrote: > P.S. in my previous life, working on 5G transport slicing (yes, i know :)) > - i needed per slice identity over the common transport, we ended up > looking at UDP port ranges, rather than DSCP - too few bits Right. The main issue is when you start requiring new/more DSCP for a purpose that is not QoS. Which by itself is not a good hard definition, but at least a starting point. Cheers Toerless > > Cheers, > Jeff > On Thu, Nov 15, 2018 at 23:37 Robert Raszuk wrote: > > > Jeff, > > > > > What architecture? > > > PBR is a form of: > > > match DSCP X > > > set next-hop Y > > > needs no interoperability... > > > > That's pretty narrow view. I could say the worst possible example :) You > > would have to either encapsulate or apply your sample config consistently > > on every hop. Br. > > > > To me DSCP can be used to map packets to different routing context, > > different plane or can be used as a parameter in flex-algorithm. > > > > Thx, > > R. > > > > > > > > > > > > On Fri, Nov 16, 2018 at 8:19 AM Jeff Tantsura > > wrote: > > > >> Tony, > >> > >> What architecture? > >> PBR is a form of: > >> match DSCP X > >> set next-hop Y > >> needs no interoperability... > >> If someone wants to describe how they use a particular vendor feature to > >> solve a particular problem in a BCP, sure, the more BCPs - the better. > >> > >> Wrt using DSCP in routing decision process - it was a bad idea back then, > >> hasn???t got any better now... besides - now we have got a toolbox that > >> wasn???t available then. > >> > >> Cheers, > >> Jeff > >> On Thu, Nov 15, 2018 at 22:56 Tony Li wrote: > >> > >>> > >>> > >>> On Nov 15, 2018, at 8:47 PM, Jeff Tantsura > >>> wrote: > >>> > >>> The question is really - what is here to standardize? > >>> > >>> > >>> > >>> There???s a fine architectural BCP here: this is how we are solving > >>> problem XYZ. Please don???t break this. > >>> > >>> Tony > >>> > >>> > ___ > Lsr mailing list > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr -- --- t...@cs.fau.de ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] LSR: Using DSCP for path/topology selection Q
Rob, Thats actually a good example, i had forgotten about that one. This is also a lot more scalable than MTR given how (if i remember correctly, you would only have O(#DSCP,#egres-PE) entries. Cheers Toerless On Thu, Nov 15, 2018 at 04:47:26PM -0800, Rob Shakir wrote: > On Thu, 15 Nov 2018 at 16:07 Toerless Eckert wrote: > > > > And btw I read Peter's note as possibility (or invitation) to define > > > algorithm which takes into account DSCP rather then a announcement that > > > this is not there and it should never be. > > > > Sure, i am only talking about the solutions that tried to use DSCP for > > routing so far. I think those failed. And when other agree and we codify > > that, then that would not exclude the option for new work (like what > > Peter may have in mind) to superceed that recommendation. > > > > A number of networks on which I have worked have used DSCP-based tunnel > selection to choose between RSVP-TE LSPs. This essentially is different > routing based on DSCP, which seems to be something that you're trying to > cover -- is that correct? > > If so, given that these are running in real networks, I find it hard to > conclude that any IETF standard should declare them as failed. > > r. > ___ > Lsr mailing list > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] LSR: Using DSCP for path/topology selection Q
Whats the current best guidance on using DSCP for selection of path, specifically for selection of topology with MTR (RFCs 4915, 5120, 7722) ? My understanding from history is that this looked like a good idea to customers first, but when implementations became available, customers really did not want to implement it because of the overloading of DSCP between QoS and routing and the resulting management complexity. Has the idea of using DSCP for path selection been re-introduced in any later work like flex-Algos ? If there could be rough consensus that this is in general a bad idea, i wonder if it would be appropriate to have a short normative document from LSR defining that the use of DSCP for topology selection is historic and not recommended anymore and make this an update to above three RFCs, maybe also pointing out that there are other methods to select a topology and those remain viable: I specifically would not like to see the actual MTR RFCs to be changed in status, because MTR actually does work quite well and is supported in products and deployed with IP multicast, even with multiple topologies for IP multicast in live-live scenarios. Thanks! Toerless ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
