Julien,
On 11/5/15 11:03 , Julien Meuric 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..."
above talks about the LSA content, not about the configuration.
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.
I would think that that would always be identical, if advertised in both
LSAs. But from the protocol encoding perspective, we can not prevent
values being different - e.g. transition case where config of SRLG on
remote node changes and two LSAs arrive asynchronously.
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. :-)
I'm afraid she did not.
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".
RFC3630:
"The extensions provide a way of describing the traffic engineering
topology (including bandwidth and administrative constraints) and
distributing this information within a given OSPF area. This
topology does not necessarily match the regular routed topology,"
If you want to advertise SRLG for a link (to be used for LFA), but you
do not want to make the link part of the traffic engineering topology,
how do you do that?
regards,
Peter
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
