Subject: [Pce] Comment on draft-ietf-pce-segment-routing-01

From: Jonathan Hardwick <[email-masked]>
Date: Wed, 25 Mar 2015 23:23:12 +0000

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

---

From: Dhruv Dhody <[email-masked]>
Date: Wed, 25 Mar 2015 18:44:48 -0500

+1,  I agree with Jon.

Perhaps a new METRIC type for MSD?

Regards,
Dhruv

On Wed, Mar 25, 2015 at 6:23 PM, Jonathan Hardwick <
[email-masked]> wrote:

> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pce
>
>

---

From: Jeff Tantsura <[email-masked]>
Date: Thu, 26 Mar 2015 00:00:17 +0000

I fully agree with the comments and thanks Jon for bringing it up.
We will work to address it.

Regards,
Jeff

On Mar 25, 2015, at 6:44 PM, Dhruv Dhody <[email-masked]<mailto:[email-masked]>> wrote:

+1,  I agree with Jon.

Regards,
Dhruv

On Wed, Mar 25, 2015 at 6:23 PM, Jonathan Hardwick <[email-masked]<mailto:[email-masked]>> wrote:
Hi Jeff

•         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
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/pce

---

From: Olivier Dugeon <[email-masked]>
Date: Thu, 26 Mar 2015 09:30:40 +0100

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
>
>
>

---

From: <[email-masked]>
Date: Thu, 26 Mar 2015 11:18:01 +0000

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:[email-masked]] De la part de Olivier Dugeon
Envoyé : jeudi 26 mars 2015 09:31
À : Jonathan Hardwick; Jeff Tantsura
Cc : [email-masked]; [email-masked]
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

·         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.

Best regards
Jon

Pce mailing list

_________________________________________________________________________________________________________________________

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.

---

From: Jonathan Hardwick <[email-masked]>
Date: Thu, 26 Mar 2015 13:24:37 +0000

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: [email-masked] [mailto:[email-masked]]
Sent: 26 March 2015 06:18
To: DUGEON Olivier IMT/OLN; Jonathan Hardwick; Jeff Tantsura
Cc: [email-masked]; [email-masked]
Subject: RE: [Pce] Comment on draft-ietf-pce-segment-routing-01

Hi,

Best regards,
GUEDREZ Rabah

Cc : [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

Hi Jonathan,

Regards,

Olivier

Best regards
Jon

Pce mailing list

Thank you.

---

From: Olivier Dugeon <[email-masked]>
Date: Thu, 26 Mar 2015 14:46:04 +0100

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:[email-masked] [mailto:[email-masked]]
> *Sent:* 26 March 2015 06:18
> *To:* DUGEON Olivier IMT/OLN; Jonathan Hardwick; Jeff Tantsura
> *Cc:* [email-masked]; [email-masked]
> *Subject:* RE: [Pce] Comment on draft-ietf-pce-segment-routing-01
>
> Hi,
>
> 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.
>
> 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:[email-masked]] *De la part de* Olivier Dugeon
> *Envoyé :* jeudi 26 mars 2015 09:31
> *À :* Jonathan Hardwick; Jeff Tantsura
> *Cc :* [email-masked] 
> <mailto:[email-masked]>; [email-masked] 
> <mailto:[email-masked]>
> *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 
> 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.
>
>     I just wanted to clarify the comment that I made at the mic today
>     as we seemed to be talking at cross-purposes.
>
>     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.
>
>     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.
>
>     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
>
>
>
>     [email-masked]  <mailto:[email-masked]>
>

-- 
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
[email-masked] <mailto:[email-masked]>

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 26 Mar 2015 14:54:54 -0000

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:[email-masked]] On Behalf Of Jonathan Hardwick
Sent: 25 March 2015 23:23
To: Jeff Tantsura
Cc: [email-masked]; [email-masked]
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

---

From: Jeff Tantsura <[email-masked]>
Date: Thu, 26 Mar 2015 15:08:23 +0000

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 <[email-masked]<mailto:[email-masked]>>
Date: Thursday, March 26, 2015 at 6:46 AM
To: Jonathan Hardwick <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Jeff Tantsura <[email-masked]<mailto:[email-masked]>>
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).

Regards

Olivier

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:[email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: 26 March 2015 06:18
To: DUGEON Olivier IMT/OLN; Jonathan Hardwick; Jeff Tantsura
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: RE: [Pce] Comment on draft-ietf-pce-segment-routing-01

Hi,

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

Hi Jonathan,

Regards,

Olivier

Best regards
Jon

Pce mailing list

Thank you.

--
[logo Orange]<http://www.orange.com>

Olivier Dugeon

fixe : +33 2 96 07 28 80
mobile : +33 6 82 90 37 85
[email-masked]<mailto:[email-masked]>

---

From: Olivier Dugeon <[email-masked]>
Date: Thu, 26 Mar 2015 18:26:16 +0100

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 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:[email-masked]] *On Behalf Of *Jonathan Hardwick
> *Sent:* 25 March 2015 23:23
> *To:* Jeff Tantsura
> *Cc:* [email-masked]; [email-masked]
> *Subject:* [Pce] Comment on draft-ietf-pce-segment-routing-01
>
> Hi Jeff
>

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 26 Mar 2015 17:51:49 -0000

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:[email-masked]] 
Sent: 26 March 2015 17:26
To: [email-masked]; 'Jonathan Hardwick'; 'Jeff Tantsura'
Cc: [email-masked]; [email-masked]
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

A

Hi Jeff

 

Best regards
Jon

---

From: Sriganesh Kini <[email-masked]>
Date: Thu, 26 Mar 2015 20:52:13 +0000

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 <[email-masked]<mailto:[email-masked]>>
Date: Thursday, March 26, 2015 at 8:08 AM
To: Olivier Dugeon <[email-masked]<mailto:[email-masked]>>, Jonathan Hardwick <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Sriganesh Kini <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Pce] Comment on draft-ietf-pce-segment-routing-01

Hi,

Great discussion!

Cheers,
Jeff

Hello Jon,

Regards

Olivier

Best regards
Jon

Hi,

Best regards,
GUEDREZ Rabah

Hi Jonathan,

Regards,

Olivier

Best regards
Jon

Pce mailing list

Thank you.

Olivier Dugeon

fixe : +33 2 96 07 28 80