Hi Julien,
please see inline:
On 11/13/15 17:47 , [email protected] wrote:
Hi Peter,
See [JM] below.
Nov. 12, 2015 - [email protected]:
Julien,
On 11/10/15 17:51 , Julien Meuric wrote:
Hi Acee,
I think we do not need to agree on the philosophical question whether
defining detour path by packet header instead of signaling states brings
the feature out of TE...
Anyway we agree that consolidating information from 3 separates LSA is
not the most efficient processing. My point is that this slight
improvement does not balance the risk of inconsistent
advertisements/configuration that the current I-D does not (even try to)
prevent.
let me disagree. Current I-D clearly states what TE Opaque LSAs are used
for.
[JM] I am happy to quote Jeff on this: "thanks to GMPLS IGP extensions
as per RFC's 4203 & 5307 SRLG info is there, it is up to implementation
how to use it."
(https://mailarchive.ietf.org/arch/msg/rtgwg/yURBLVi2LqrEz33wKkauV0j9cmA)
Jeff is a co-author of the ospf-te-link-attr-reuse, so I let him express
his opinion, but he has responded on the list already saying:
"I'm familiar with at least 2 implementations which have this issue,
this draft solves real problem."
The risk is when you do what you propose to do as it breaks the existing
TE
[JM] This is different from Acee's point: "usage of the TE LSAs for
non-TE purposes was NEVER standardized". It is not about breaking, it is
about documenting use cases beyond the original one.
- e.g. you advertise the link in TE Opaque LSA and some remote router
would try to establish a TE path via such link, even though the link is
not enabled for that. Result is that the signaling would keep failing or
in worst case, when signaling is not involved, traffic will be dropped
when trying to use such link.
[JM] Supposing I am an operator who is playful enough to manage a
network area using a topology for TE traffic that does not match the
IP/LDP topology (you may find this realistic, I do not). Then, a router
ignoring that an SRLG-enabled link has no available bandwidth/a specific
affinity/a non-PSC switching capability/etc. is misbehaving.
well, that is not necessarily true, for example 0 bandwidth tunnels are
often used. RFC3630 does not mandate bandwidth, affinity or any other
link attributes in TE Opaque LSAs. Link Type and Link ID sub-TLVs are
mandatory, rest are optional.
Anyway, this moves beyond the issue at stake here. Acee states that some
implementations need new definitions to go beyond the original use case.
I would like to limit the number of fields opening the doors to
operational inconsistencies. In these regards, an "applicability
statement of TE LSA parameters beyond MPLS-TE" may be a way to address
our concerns.
I'm afraid we can not afford to change the RCF that has been published
12 years back. This would make it backward incompatible.
Enjoy the week-end,
you too!
thanks,
Peter
Julien
regards,
Peter
Regards,
Julien
Nov. 07, 2015 - [email protected]:
Hi Julien,
One such non-TE application where there is a clear advantage of
advertising these attributes is segment routing TI-LFA. In addition to
all
the detriments of requiring advertisement of TE LSAs when TE is not
enabled, one would need to consolidate information for a link from 3
separate LSAs (the base Router-LSA, the prefix-list attribute LSA for
the
adjacency SID, and the TE LSA). Clearly, it is better to advertise the
applicable attributes in the Prefix/Link Attribute LSA and reduce this
burden. You will note that this advantage isn’t apparent in IS-IS where
everything is advertised in one monolithic LSP.
Thanks,
Acee
On 11/5/15, 7:03 PM, "OSPF on behalf of Julien Meuric"
<[email protected] on behalf of [email protected]> wrote:
Hello Peter,
Nov. 05, 2015 - [email protected]:
Hi Julien,
On 11/5/15 09:12 , Julien Meuric wrote:
Hi Jeff,
Following the WG session yesterday, I'm glad to (lately) join the
thread. Please, see my comments below as [JM].
Oct. 26, 2015 - [email protected]:
Hi,
No hats
I'm familiar with at least 2 implementations which have this issue,
this draft solves real problem.
Regards,
Jeff
[JM] Then you may consider patching them to do parameter
duplication on
the receiver side, not on the wire and/or the emitter
configuration...
Do you imagine operational people tearing hair out while trying to
guess
if they need to configure SRLGs in here, there or both? All the
more as
two places would multiply configuration discrepancies.
above is incorrect.
Nobody is proposing to configure things like SRLG on multiple places.
[JM] Actually you do in the I-D: "it is expected that the information
would be identical. If they are different..."
You configure it on a single place, as you do today. If IGP is
enabled
for global SRLG protection, IGP pulls the SRLGs and advertise them in
the Extended Prefix LSA. If TE is enabled and want to use SRLGs, it
pulls it from the same place, form the TE Opaque LSA and asks IGP to
flood it.
[JM] This reads to me like "in case both types of LSAs are used,
values
MUST be identical". This is very different from the loose text in your
I-D.
In the I-D, the beginning and the end of section 3.1 provide a good
summary:
- "One approach for advertising link attributes is to _continue_ to
use
TE Opaque LSA"
- advantages: "no additional standardization requirement", "link
attributes are only advertised once".
I cannot agree more on these.
have you read the "disadvantage" section as well?
[JM] Of course not, since Shraddha already solved them in his original
e-mail. :-)
In other words, some new use cases, not matching the original
one, do
not justify to allocate new code points to the same information (cf.
IS-IS non-issue). In the IETF, uses cases aim at scoping protocol
work,
they aren't made to limit protocol future uses.
I;m afraid you are missing the point.
TE Opaquer LSA are defined as LSAs that advertise TE topology that is
disjoint from the IGP topology (RFC3630). We can NOT make the link
part
of the TE topology, just because we want to advertise SRLG or some
other
attribute that is used by IGP for LFA - that would break the RFC3630.
[JM] Indeed, I am missing the point where a link state protocol is
forbidden to access the link parameters it is distributing in its link
state advertisements. Please, point me to the section from RFC 3630 it
"breaks".
thanks,
Peter
[JM] You're welcome,
Julien
Cheers,
Julien
_______________________________________________
OSPF mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ospf
.
_______________________________________________
OSPF mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ospf
.
_________________________________________________________________________________________________________________________
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.
.
_______________________________________________
OSPF mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ospf
