Olivier,
please see inline:
On 27/05/2019 16:50, [email protected] wrote:
Peter,
Please see below my answers.
Le 24/05/2019 à 12:02, Peter Psenak a écrit :
Olivier,
please see inline:
On 23/05/2019 11:56 , [email protected] wrote:
Dear all
As there is no more exchange about the two mentioned drafts since 3 weeks, I'll
try to summarize the exchange and
the requested modifications.
The drafts proposed to extended IS-IS respectively OSPF to advertise new TE
parameters to overcome 2 issues:
1 - Topology incongruence between the IGP and TE
2 - Provide different parameters per application
For the first point, topology incongruence is not due to the protocol itself
but to the fact that an operator
may activate or not TE information on all links of its network. Indeed, RFC3630
and RFC5305 precise that TE
information are Optionals.
However, in both drafts, the term RECOMMENDED is used, which IMHO not solve the
problem. An operator keeps the choice
to activate or not this new TE information leading again to an incongruence
network topology. At least, wording
need to be change to MUST or MANDATORY. But, why not just change the wording of
RFC3630 and RFC5305 ?
incongruency between IGP and TE topology is a fundamental assumption and the
whole TE technology has been built around it. It is a reality and we can not
change it. Please live with it.
[OD] OK. But in this case, in isis draft, change the Introduction section as it
clearly mention that the draft
will solve these issues:
"
If the topologies are fully
congruent this may not be an issue, but any incongruence leads to
ambiguity.
"
and
" This document defines extensions which address these issues."
Which is false.
why would it be false? What is your point?
[ ... ]
For the second point, TE information are related to a link not an application
even if at the origin, RFC3630 and RFC5305
were design for RSVP-TE. It is not mention in the RFCs that they could not be
applicable to other protocol / application.
well, let me disagree. Look at the name of those two (and other) RFCs. They all have
"Traffic Engineering" in their name.
It is also well known, that advertisement of these link attributes cause many
implementations to infer that RSVP signalling is enabled on a link. Please look
at:
https://tools.ietf.org/html/draft-hegde-isis-advertising-te-protocols-03
[OD] This is an implementation problem, not a protocol or standard problem due
to a particular interpretation
of the RFCs, even if many vendors do it. And, as you mention, the draft from
hedge are much more simpler.
I don't agree. The old RFCs are written in a way they are and
interpreted by most of the vendors the similar way. We are not going to
change something that has been there for 20 years!
WG has decided to take our drafts as a solution, not the hedge one.
Please accept that decision which has been made couple of years back for
a good reason.
If the idea, in liaison to first point, it to determine is an application /
protocol is enable / disable on a given link,
even if their have been not selected, drafts
draft-hegde-ospf-advertising-te-protocols-01.txt and
draft-hegde-isis-advertising-te-protocols-03.txt are largely sufficient as it
is not necessary to duplicate link TE
information. In addition, Router Information already provides indication on the
support of SR by this router (presence
of SRGB) where all IGP links are de-facto SR enable.
no, the point is that in many implementations advertising of the existing RSVP
TE link attributes cause the head end to believe that RSVP is enabled on the
link, which may cause problems if it is not and the link attribute is
advertised to serve other then RSVP TE application.
[OD] Again, this is implementation specific (see above)
don't agree.
Then, GMPLS specific attributes are not taken into account in these drafts.
=> GMPLS must be considered as another application and specific GMPLS
attribute must be part of the drafts
=> or standardised only SABML / UDABML flags without duplicating TE information
I do not understand why we need to differentiate between RSVP TE and GMPLS. In
IGPs these has always been the same and we provisioned RSVP TE as an
application in our drafts.
[OD] Both draft are redefined part of TE link attributes. However, only IP link
attributes have been defined. Specific
GMPLS link attributes e;g. switching capabilities, are not defined. These
missing attributes must be take into
consideration if we don't want to have both (old and new) link attributes
advertisement in the same network.
we are not attempting to make all GMPLS attributes application specific.
We added those that make sense to be app specific. Rest can be
advertised in the existing way. There is no problem.
And I forgot to mention one more application which is not take into account.
RFC 5316 for IS-IS and RFC 5392 for OSPF
define how to advertise inter-domain information. Both RFC mention that TE
information could complement these information
While for ISIS all attributes are include in TLV 22, for OSPF this is advertise
in Opaque LSA Type 6. As in general,
operator will not activate protocol, except BGP, mostly for security reason on
inter-domain link, how I could use new
TE link attributes define in these draft in this application ? Is a SABM and/or
UDABM set to 0 is authorized ?
yes, please see section 4.1. of the draft-ietf-isis-te-app:
thanks,
Peter
If not
another bit is necessary to take into consideration inter-domain link. And, for
this particular application, remote AS
and remote IP address link attributes need to be added.
[ ... ]
Regards
Olivier
_________________________________________________________________________________________________________________________
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.
_______________________________________________
Lsr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lsr
