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 informationfor 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 TEDon 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 https://www.ietf.org/mailman/listinfo/pce ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
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; 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.orgmailto: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. ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
Re: [Pce] Comment on draft-ietf-pce-segment-routing-01
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] Sent: 26 March 2015 06:18 To: DUGEON Olivier IMT/OLN; Jonathan Hardwick; Jeff Tantsura Cc: draft-ietf-pce-segment-rout...@tools.ietf.org; 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.orgmailto:draft-ietf-pce-segment-rout...@tools.ietf.org; pce@ietf.orgmailto: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.orgmailto: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
Re: [Pce] Comment on draft-ietf-pce-segment-routing-01
Hello Adrian, I understand your point concerning the existing implementation and backward compatibility which motivate your answer. Now, looking to your picture, how the NMS/Controller acting as PCC know the MSD value of blue / green / yellow routers ? especially if they are all different ? By management plane ? I would not tomanage such database manually on large network ( 1000 PE). Letting PE advertise their MSD in SR Router capabilities will be safer. There is also another problem. Suppose that on a router you have different revision of hardware (common case in operational network where you mix in the same backplane different cards that support interfaces) with different capabilities, resulting in different MSD.Indeed, in general, label stacking is a hardware operation that take place in interface or master cards where interface are located. How could I manage this ? Regards, Olivier Le 26/03/2015 15:54, Adrian Farrel a écrit : I just drew the attached to make sure there is clarity. I think, in view of the existing implementations, it would be good to add the function in a backward compatible way. I think this can be done by saying that the maxStack on the Open becomes the default used in all computations for the PCC unless a specific value is supplied on an individual computation request. A *From:*Pce [mailto:pce-boun...@ietf.org] *On Behalf Of *Jonathan Hardwick *Sent:* 25 March 2015 23:23 *To:* Jeff Tantsura *Cc:* pce@ietf.org; draft-ietf-pce-segment-rout...@tools.ietf.org *Subject:* [Pce] Comment on draft-ietf-pce-segment-routing-01 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 https://www.ietf.org/mailman/listinfo/pce ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
Re: [Pce] Comment on draft-ietf-pce-segment-routing-01
Hi, I just drew a picture to show a case where there is not a one-to-one relationship between PCEP session and PCC. You have two questions: 1. How does the PCC know the capabilities of the LSRs it controls and how does it control them? Answer: don't care :-) 2. What if an LSR has different capabilities for different cards? Answer: Easy solution is to use Jeff's picture (PCC is LSR) and my solution (maxStack is a per PCReq parameter). But note that the choice of card might depend on the selected first hop in the path, in which case you are going to need to make maxStack a property of the links in the TED at least for the ingress LSRs. A From: Olivier Dugeon [mailto:olivier.dug...@orange.com] Sent: 26 March 2015 17:26 To: adr...@olddog.co.uk; 'Jonathan Hardwick'; 'Jeff Tantsura' Cc: draft-ietf-pce-segment-rout...@tools.ietf.org; pce@ietf.org Subject: Re: [Pce] Comment on draft-ietf-pce-segment-routing-01 Hello Adrian, I understand your point concerning the existing implementation and backward compatibility which motivate your answer. Now, looking to your picture, how the NMS/Controller acting as PCC know the MSD value of blue / green / yellow routers ? especially if they are all different ? By management plane ? I would not to manage such database manually on large network ( 1000 PE). Letting PE advertise their MSD in SR Router capabilities will be safer. There is also another problem. Suppose that on a router you have different revision of hardware (common case in operational network where you mix in the same backplane different cards that support interfaces) with different capabilities, resulting in different MSD. Indeed, in general, label stacking is a hardware operation that take place in interface or master cards where interface are located. How could I manage this ? Regards, Olivier Le 26/03/2015 15:54, Adrian Farrel a écrit : I just drew the attached to make sure there is clarity. I think, in view of the existing implementations, it would be good to add the function in a backward compatible way. I think this can be done by saying that the maxStack on the Open becomes the default used in all computations for the PCC unless a specific value is supplied on an individual computation request. A From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Jonathan Hardwick Sent: 25 March 2015 23:23 To: Jeff Tantsura Cc: pce@ietf.org; draft-ietf-pce-segment-rout...@tools.ietf.org Subject: [Pce] Comment on draft-ietf-pce-segment-routing-01 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 dont 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 https://www.ietf.org/mailman/listinfo/pce ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
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] *Sent:* 26 March 2015 06:18 *To:* DUGEON Olivier IMT/OLN; Jonathan Hardwick; Jeff Tantsura *Cc:* draft-ietf-pce-segment-rout...@tools.ietf.org; 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
Re: [Pce] Comment on draft-ietf-pce-segment-routing-01
Hi, The PCE should take into account both the RLD and MSD when computing the label stack. Draft-ietf-mpls-spring-entropy-label has some examples. Completely agree on aligning terminology. draft-ietf-mpls-spring-entropy-label and draft-xu-ospf-mpls-elc also need to reconcile the acronyms RLD and RLSD. I also have a suggestion for draft-ietf-pce-segment-routing – Since it is trying to express the maximum number of stack elements that can be pushed at the ingress, the appropriate acronym seems to be MSP (Maximum Stack PUSH-operations) capability. Sri From: Jeff Tantsura jeff.tants...@ericsson.commailto:jeff.tants...@ericsson.com Date: Thursday, March 26, 2015 at 8:08 AM To: Olivier Dugeon olivier.dug...@orange.commailto:olivier.dug...@orange.com, Jonathan Hardwick jonathan.hardw...@metaswitch.commailto:jonathan.hardw...@metaswitch.com, rabah.gued...@orange.commailto:rabah.gued...@orange.com rabah.gued...@orange.commailto:rabah.gued...@orange.com Cc: draft-ietf-pce-segment-rout...@tools.ietf.orgmailto:draft-ietf-pce-segment-rout...@tools.ietf.org draft-ietf-pce-segment-rout...@tools.ietf.orgmailto:draft-ietf-pce-segment-rout...@tools.ietf.org, pce@ietf.orgmailto:pce@ietf.org pce@ietf.orgmailto:pce@ietf.org, Sriganesh Kini sriganesh.k...@ericsson.commailto:sriganesh.k...@ericsson.com Subject: Re: [Pce] Comment on draft-ietf-pce-segment-routing-01 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.commailto:olivier.dug...@orange.com Date: Thursday, March 26, 2015 at 6:46 AM To: Jonathan Hardwick jonathan.hardw...@metaswitch.commailto:jonathan.hardw...@metaswitch.com, rabah.gued...@orange.commailto:rabah.gued...@orange.com rabah.gued...@orange.commailto:rabah.gued...@orange.com Cc: draft-ietf-pce-segment-rout...@tools.ietf.orgmailto:draft-ietf-pce-segment-rout...@tools.ietf.org draft-ietf-pce-segment-rout...@tools.ietf.orgmailto:draft-ietf-pce-segment-rout...@tools.ietf.org, pce@ietf.orgmailto:pce@ietf.org pce@ietf.orgmailto:pce@ietf.org, Jeff Tantsura jeff.tants...@ericsson.commailto: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
Re: [Pce] Comment on draft-ietf-pce-segment-routing-01
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.commailto:olivier.dug...@orange.com Date: Thursday, March 26, 2015 at 6:46 AM To: Jonathan Hardwick jonathan.hardw...@metaswitch.commailto:jonathan.hardw...@metaswitch.com, rabah.gued...@orange.commailto:rabah.gued...@orange.com rabah.gued...@orange.commailto:rabah.gued...@orange.com Cc: draft-ietf-pce-segment-rout...@tools.ietf.orgmailto:draft-ietf-pce-segment-rout...@tools.ietf.org draft-ietf-pce-segment-rout...@tools.ietf.orgmailto:draft-ietf-pce-segment-rout...@tools.ietf.org, pce@ietf.orgmailto:pce@ietf.org pce@ietf.orgmailto:pce@ietf.org, Jeff Tantsura jeff.tants...@ericsson.commailto: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.commailto: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.orgmailto:draft-ietf-pce-segment-rout...@tools.ietf.org; pce@ietf.orgmailto: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,
