Hi, Great discussion!
Let’s try no to mix things. 1. Entropy labels (LB for ECMP/LAG) use case has been described in draft-ietf-mpls-spring-entropy-label, this ID defines new capability - RLD - Readable Label Depth which is used to define how <ELI, EL> (or multiple of those) should be instantiated. 2. draft-xu-isis-mpls-elc and draft-xu-ospf-mpls-elc define RLSDC -Readable Label Stack Deepth Capability which is used to advertise the capability of the router to read a label stack of a particular depth. Back to the original discussion – Jon is right – MSD is significant on the ingress only since only ingress knows total stack depth and is in charge of pushing it. Adrian’s proposal looks good to me – we will discuss it among coauthors and come back ASAP. Thanks everyone for your valuable comments! P.S. We should really agree on terminology :) Cheers, Jeff From: Olivier Dugeon <olivier.dug...@orange.com<mailto:olivier.dug...@orange.com>> Date: Thursday, March 26, 2015 at 6:46 AM To: Jonathan Hardwick <jonathan.hardw...@metaswitch.com<mailto:jonathan.hardw...@metaswitch.com>>, "rabah.gued...@orange.com<mailto:rabah.gued...@orange.com>" <rabah.gued...@orange.com<mailto:rabah.gued...@orange.com>> Cc: "draft-ietf-pce-segment-rout...@tools.ietf.org<mailto:draft-ietf-pce-segment-rout...@tools.ietf.org>" <draft-ietf-pce-segment-rout...@tools.ietf.org<mailto:draft-ietf-pce-segment-rout...@tools.ietf.org>>, "pce@ietf.org<mailto:pce@ietf.org>" <pce@ietf.org<mailto:pce@ietf.org>>, Jeff Tantsura <jeff.tants...@ericsson.com<mailto:jeff.tants...@ericsson.com>> Subject: Re: [Pce] Comment on draft-ietf-pce-segment-routing-01 Hello Jon, Yes you agree. From the pure Segment Routing and MPLS point of view. Now, looking to load balancing, it is quiet different. When you setup LAG or Load Balancing, the router perform a hash on the packet header to determine on which interface to send the packet. In general, the has allow a router to send all packets that belongs to the same session goes to the same interface / path. Now, some hardware limitation impose a limitation on the size of the label stack in order to continue to operate the hash function on the IP header located after the label stack. In the label stack is too huge, the hash function will operate across the beginning of the IP header and the end of label stack resulting on non optimal session segregation. In some case it could not be acceptable and lead into problem from an operational point of view. For example, it could cause some packets de-ordering (packets of the same session not follow the same path) that could be not supported by some application e.g. VoIP. So, if for example a PE router accept a MSD of 10 labels and a P router accept a MSD of 5 labels, the computed SR path must take into account that when reaching the P router, le Segment packet must not have a label stack greater than 5 (or 6 depending if the hash is perform before or after the POP operation). Hope this clarify our requests. Regards Olivier Le 26/03/2015 14:24, Jonathan Hardwick a écrit : Olivier, Rabah, Please could you clarify something for me? I’m not sure that the MSD of the intermediate nodes has the same significance as the MSD of the ingress node. My understanding is that the ingress node is often limited by hardware in the maximum depth of the SID stack that it can push onto each packet. The intermediate nodes do not have to push SIDs – I thought that they would just route on the top-most SID in the stack and sometimes remove the top-most SID from the stack. If that’s true then the MSD path constraint does not apply to them. Have I misunderstood? Best regards Jon From:rabah.gued...@orange.com<mailto:rabah.gued...@orange.com> [mailto:rabah.gued...@orange.com] Sent: 26 March 2015 06:18 To: DUGEON Olivier IMT/OLN; Jonathan Hardwick; Jeff Tantsura Cc: draft-ietf-pce-segment-rout...@tools.ietf.org<mailto:draft-ietf-pce-segment-rout...@tools.ietf.org>; pce@ietf.org<mailto:pce@ietf.org> Subject: RE: [Pce] Comment on draft-ietf-pce-segment-routing-01 Hi, I totally agree with Olivier and Jonathan on this. to encompass all the varieties of PCE/PCC architectures, the MSD should be considered as additional constraint by the path computation engine just like the BANDWIDTH, the only scenario I can think of where the MSD must be announced by the PCC is inter-PCE collaboration and the right place would be for it is PCReq. I Agree with Olivier a support his proposition. considering only the PCC MSD and not the intermediate nodes by the path computation engine will result in paths that don’t behave as expected, (specially for load balancing in a loose path scenario ),the PCE must have in its TED all the MSDs of all the nodes (PE and P) in its domain, therefore the MSD should advertised by the IGP (OSPF, ISIS, BGP-LS) just like the SRLGs, where the path computation engine will consider the MSDs of the ingress and intermediate to compute the path. Best regards, GUEDREZ Rabah De : Pce [mailto:pce-boun...@ietf.org] De la part de Olivier Dugeon Envoyé : jeudi 26 mars 2015 09:31 À : Jonathan Hardwick; Jeff Tantsura Cc : draft-ietf-pce-segment-rout...@tools.ietf.org<mailto:draft-ietf-pce-segment-rout...@tools.ietf.org>; pce@ietf.org<mailto:pce@ietf.org> Objet : Re: [Pce] Comment on draft-ietf-pce-segment-routing-01 Hi Jonathan, I agree with you. The MSD is purely a local information attached to the router. To correctly manage this information for Segment Path computation, the PCE must be aware of MSD of each router, not only the PE, but also the P routers. So, the best way is to add MSD metric announcement in the router SR capabilities sub-TLV (see e.g. draft-ietf-isis-segment-routing-extensions-03.txt page 23 section 3.1). So that, the PCE get the information in its TED on a per node basis. Then it is not necessary to add it in the OPEN message, but eventually, move it on the PCReq/PCInit/PCRept message as a constraint for the SR path computation. Now, the main problem, is who can be in charge to propose this new MSD metric ? PCE WG, SPRING WG or IS-IS/OSPF WG ? Regards, Olivier Le 26/03/2015 00:23, Jonathan Hardwick a écrit : Hi Jeff I just wanted to clarify the comment that I made at the mic today as we seemed to be talking at cross-purposes. The draft sets a maximum SID depth in the Open message, which effectively creates an implicit constraint on all queries that are sent over the PCEP session, such that returned paths must not have a SID stack depth greater than the MSD. I think this is wrong, and that the MSD should instead be sent as an explicit constraint on each query. Here is my reasoning. In the PCE architecture it is wrong to assume that the PCC and the ingress router are the same device. There are at least two cases where it is not. · In some network management architectures, the PCC is a network management tool. The network management tool may have many ingress routers in its jurisdiction, each with a different MSD, so it is not true to say that the MSD is a constant for the PCC-PCE session. · In inter-domain routing there is PCE-PCE communication between domains. One of the PCEs plays the role of PCC and is acting on behalf of all edge routers in its domain (or perhaps some domain further upstream). Again, the MSD is not constant on the PCE-PCE session. I don’t think that we should rule either of these scenarios out of segment routing, even if they are not the first scenarios that everyone is targeting. At some point we will want to do them and we do not want to re-do the work that we are doing today to make them work. Best regards Jon _______________________________________________ Pce mailing list Pce@ietf.org<mailto:Pce@ietf.org> https://www.ietf.org/mailman/listinfo/pce _________________________________________________________________________________________________________________________ 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. -- [logo Orange]<http://www.orange.com> Olivier Dugeon Senior research engineer in QoS and network control Open Source Referent Orange/IMT/OLN/WTC/IEE/OPEN fixe : +33 2 96 07 28 80 mobile : +33 6 82 90 37 85 olivier.dug...@orange.com<mailto:olivier.dug...@orange.com>
_______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
