Hi Bruno,
thanks for your comments, please see responses inline.
We can work on details as we progress the draft in the WG.
What I would like to hear from you at this point is whether you support
the idea described in the draft.
On 04/11/16 16:50 , [email protected] wrote:
Hi authors,
Although I'm more familiar with IS-IS (nobody's perfect ;-) ), please find
below some proposed comments
1) meaning of "TE"
As already expressed in a meeting, I'd like the document to clarify the meaning of "TE". I suspect that in
this document it is used to mean "RSVP-TE" while some readers could understand it as "Traffic
Engineering application". IOW, is SR-TE part of "TE" or not?
TE in the context of the draft means RSVP based TE.
In particular, this needs to be crystal clear in the recommended approach.
Current text is:
"3.3. Selected Approach
It is RECOMMENDED to use the Extended Link Opaque LSA ([RFC7684] to advertise
any link attributes used for non-TE purposes in OSPFv2"
sure, we can make that clarification.
IMHO, I would interpret this text as SR-TE must not use the Extended Link
Opaque LSA ([RFC7684], hence presumably must use the TE Opaque TSA.
But I suspect that this is not the intent of the authors.
In a long run, we would like the SRTE to use the Extended Link Opaque
LSA ([RFC7684].
2) As a minor comment, I'm not that convinced with (or don't understand well)
the argument 2 in section 3.2
"The TE Opaque LSA remains truly opaque to OSPFv2 as originally defined in
[RFC3630]. Its content is not inspected by OSPFv2 and OSPFv2 acts as a pure
transport."
Why should RSVP-TE info be truly opaque to OPSFv2 while SR-TE or LFA info
should not be opaque?
both are opaque to OSPF. What is important is that SRTE advertisements
would not cause any node in the network to believe that RSVP TE is
available on the link - that's why we need to separate the two
advertisements.
3) §5 " Bit-1: LFA"
Could you please clarify what you mean by "LFA"?
Do you mean "LFA" ie RFC 5286? Or *LFA to include LFA, RLFA, DLFA, TI-LFA? (but this would not
cover some possibly future solution) Or "FRR" in which case this would include RSVP-TE FRR? or
"IP FRR"? (but I'm afraid this term is loosely defined)...
any type of LFA. These is detail though and subject to changes if required.
4) §5
"If, however,
another advertisement of the same link attribute includes Application
Bit-Mask in the Extended Link Attribute sub-TLV, applications that
are listed in the Application Bit-Mask of such Extended Link
Attribute sub-TLV SHOULD use the attribute advertisement which has
the application specific bit set in the Application Bit-Mask."
Why SHOULD rather than MUST? A priori the principle is that the most specific
information prevails. i.e the attribute advertisement which has
the application specific bit set in the Application Bit-Mask is to be used.
sure, this is a small detail. No problem to change to MUST.
5) §5 I have a clarification question with regards to the use of "Unidirectionnal
Residual Bandwidth" for non TE applications (i.e. for OSPFv2 Extended Link TLV).
What would be the meaning of this sub-TLV for non-TE application, given that RFC
7471 seems to have defined a meaning which is RSVP-TE specific "For a link or
forwarding adjacency,
residual bandwidth is defined to be Maximum Bandwidth [RFC3630] minus the
bandwidth currently allocated to RSVP-TE LSPs."
Same question for "Available Bandwidth" which definition is also RSVP-TE
specific.
the short answer is that these are bandwidth minus the bandwidth
allocated/used by RSVP TE.
Related question for "Utilized Bandwidth", and * "Unidirectional Link Delay"
which seems to measure a specific physical property, which does not seem to be possibly different
on a per application basis.
e.g. " The delay advertised by this sub-TLV MUST be the delay from the advertising
node to its neighbor (i.e., the forward path delay)." How could this value be
application specific?
we can debate which attributes make sense to be application specific.
I'm open for that discussion.
6) §6 backward compatibility
Thanks for considering the backward compatibility. I fell that one case is
missing.
"If there are also OSPF routers using the link attributes
described herein for Non-RSVP applications, OSPF routers in the
routing domain will also need to advertise these attributes in OSPF
Extended Link Attributes LSAs [RFC7684]."
At the beginning, some OSPF routers not (yet) upgraded to be compliant with this spec, won't be
capable of advertising these attributes in OSPF Extended Link Attributes LSAs. So "new"
routers won't be able to understand "old" routers.
new routers would always understand the old advertisements.
A more graceful way to introduce this change, would be to ask "new"
routers also listen to "old" routers. i.e. if no "TE attributes" is
advertised in Extended Link Attributes LSAs, then look for this
attributes in TE Opaque LSAs, and use that information for "non-TE
applications".
absolutely, that is the idea. I will make sure the text is clear on that.
thanks,
Peter
(Using a node capability would a priori seems easier, but this is a detail)
Thanks,
Regards,
-- Bruno
_________________________________________________________________________________________________________________________
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
