Hi Stephane,
On 8/26/15 09:25 , [email protected] wrote:
Hi Pushpasis,
I just want to remember that the discussion is not only for MT, but there was
also a thread for per algorithm SRGB (as presented in Prague). IMO, there must
be some consistency in the choice we do.
agreed.
Regarding encoding nothing is impossible (as example a new subTLV can be
created ensuring backward compatibility).
true, but before you decide to add a new subTLV, there needs to be a
requirement which can not be satisfied with the existing ones.
I would say let's first have a consensus of what is good to do independently of
the encoding.
I believe we all agree on what is "good to do". There are multiple ways
how that can be done. One that works today and one that requires change
in SR architecture and protocol encoding.
thanks,
Peter
Best Regards,
-----Original Message-----
From: Pushpasis Sarkar [mailto:[email protected]]
Sent: Wednesday, August 26, 2015 07:36
To: Les Ginsberg (ginsberg); Uma Chunduri; LITKOWSKI Stephane SCE/IBNF; Peter
Psenak (ppsenak); Eric Rosen; SPRING WG
Subject: Re: [spring] SRGBs, indexes, and topologies within a domain
Hi Les,
On 8/26/15, 7:13 AM, "Les Ginsberg (ginsberg)" <[email protected]> wrote:
[Les:] Topology specific SRGBs requires a specification change for the IGPs. The new
advertisements are NOT backwards compatible w existing implementations. So we cannot
simply say "do what you please".
Peter has repeatedly made this point - and also pointed out that since the
prefix advertisements as currently defined in the IGP drafts includes topology
identifiers including the topology identifier in the SRGB advertisement is
redundant.
[Pushpasis] Why not add a MT-SR_Capability Sub/TLV then? That way it won’t
break backward compatibility?
Thanks
-Pushpasis
_________________________________________________________________________________________________________________________
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.
_______________________________________________
spring mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/spring
_______________________________________________
spring mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/spring
