Hi John,
I agree with most changes but the one below. If we get rid of the
MPLS-specific langage, then I feel the term "router" isn't generic
enough. Depending on the data plane technology, the head-end/ingress may
indeed be referred to as a ROADM, a cross-connect, a bridge, a switch,
etc. I think terms like "node" or "network element" would resolve that
issue.
Thanks,
Julien
On 14/12/2023 17:10, John Scudder wrote:
I went ahead and made these changes, they’re in version 07-05. Chairs, please
take a look and let me know if you’re fine with this version. If so, the
approval process is complete and I’ll notify the Secretariat.
Thanks,
—John
On Dec 14, 2023, at 9:56 AM, Eric Vyncke (evyncke)<[email protected]> wrote:
[...]
2) in the same vein, the 2nd paragraph is only about (G)MPLS with terms like
LSR and LSP.
As in,
OLD:
In this architecture path computation does not necessarily occur on
the head-end (ingress) LSR, but on some other path computation entity
that may not be physically located on each head-end LSR. The TEAS
Working Group is responsible for defining and extending architectures
for Traffic Engineering (TE) and it is expected that the PCE and TEAS
WGs will work closely together on elements of TE architectures that
utilize PCE.
NEW:
In this architecture path computation does not necessarily occur on
the head-end (ingress) router, but on some other path computation entity
that may not be physically located on each head-end router. The TEAS
Working Group is responsible for defining and extending architectures
for Traffic Engineering (TE) and it is expected that the PCE and TEAS
WGs will work closely together on elements of TE architectures that
utilize 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
[email protected]
https://www.ietf.org/mailman/listinfo/pce
