Hi Stephane,
On 8/26/15 18:17 , [email protected] wrote:
Hi,
Just to know, is there some implementation today supporting MT for SPRING ? The
other point is : if yes, does someone use it in a live network ? If no, there
is no issue to change.
I agree that a migration is not easy, but coming back to previous sentence,
honestly I think no one use MT SPRING today ... so no migration expected.
the fact that there are no existing MT/algo deployments of SR using the
existing encoding does not mean there will never be ones in the future.
Unless you remove those fields in the existing encoding anyone can use
them to deploy MT/algo with SR, you can not prevent that.
My point is that having two mechanisms to do the same thing is bad idea
to start with, because of the reasons I mentioned earlier.
thanks,
Peter
For algorithm, AFAIK, no one support multiple algorithm today, so we can do
what we want as far as it does not break algo#0 today.
Stephane
-----Original Message-----
From: Peter Psenak [mailto:[email protected]]
Sent: Wednesday, August 26, 2015 17:40
To: Pushpasis Sarkar; Les Ginsberg (ginsberg); LITKOWSKI Stephane SCE/IBNF; Uma
Chunduri; Eric Rosen; SPRING WG
Subject: Re: [spring] SRGBs, indexes, and topologies within a domain
Hi Pushpasis,
On 8/26/15 16:44 , Pushpasis Sarkar wrote:
Hi Les,
On 8/26/15, 7:45 PM, "Les Ginsberg (ginsberg)" <[email protected]> wrote:
Stephane -
Implementations based on the drafts that currently exist advertise a topology
independent SRGB. A SID which is advertised in a specific MT Prefix
Reachability advertisement is interpreted as an index into the topology
independent SRGB. This is NOT compatible with an implementation which is
written assuming that a SID is an index into a topology specific SRGB. So the
introduction of topology specific SRGBs would have to be supported network-wide
before it could be deployed. Sub-TLVs cannot resolve this incompatibility.
[Pushpasis] What if we use the current SR-capability sub-TLVs only for single
topology deployments? And use a new MT-SR-Capability SubTLV for MT deployments?
Please note, I am not saying MT cannot be supported with current SR-Cap SubTLV.
It can be, but with the limitation (as I like to see this cuurently) is that we
MUST use separate SID-index for the same prefix in separate topologies. If
operator does not want to live with the limitation then all the vendor
implementations must implement the new MT-SR-Cap SubTLV and make it happen. If
the operator can live with the implementation they continue with per-topology
SID-index and single SRGB for all topology.
above would require vendors to implement both options. For operators managing
transitions between one option to the other would be difficult.
Interoperability with the implementations that only support one option would
become problematic.
Do we really want to create all this? Does the gain we would get with per
topo/algo SRGB justify all this, especially given that the gain is not
functional, but rather operational and fairly limited?
thanks,
Peter
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
