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
