Re: [Lsr] Summary of WGLC discussion about draft-ietf-isis-te-app-06.txt and draft-ietf-ospf-te-link-attr-reuse-07.txt

[Peter Psenak <[e-mail]>]

Olivier,

please see inline:

On 27/05/2019 16:50, [e-mail] 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 , [e-mail] 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.
>
>
>