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