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

From: <[email-masked]>
Date: Thu, 23 May 2019 11:56:13 +0200

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 ?

In addition, no operator express explicitly that their are concern by topology incongruence.

 => Introduction sections should be improved to better justify why we need to modify TE link advertisement
 => Wording must be revise to avoid incongruence topology

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.

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.

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

Network operational transition issues are poorly address in these drafts. Indeed, router upgrade
take time in large scale network (several weeks even several months) leading cohabitation of the 2 systems which
introduce a large degree of complexity for operators for network management.

 => Improve migration section to help operator during the transition phase

And finally, if we go a bit further, dealing with SDN, all these new TE information need to be learnt by and SDN
controller e.g. a PCE, which naturally conduct to use BGP-LS for this purpose. However, recent discussion in idr WG
mention that there is already too many attributes that have been standardised dealing with problem with the maximum
size of BGP message. These new TE information will also certainly appear as duplicate regarding RFC7752 and RFC8571.

So, I would ask authors of both drafts to know how they intend to manage this problem ?
For us, if these new TE information could not be learnt through BGP-LS, there is no interest to use them.

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.

---

From: Peter Psenak <[email-masked]>
Date: Fri, 24 May 2019 12:02:10 +0200

Olivier,

please see inline:

> 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.

> In addition, no operator express explicitly that their are concern by topology incongruence.

that does not mean we can get rid of it. We can not mandate the 
congruency now, 20 years after i has been defined and deployed all over 
the place.

>  => Wording must be revise to avoid incongruence topology

absolutely not!

> 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

> 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.

>  => 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.

> introduce a large degree of complexity for operators for network management.

I disagree. The sections on the backward compatibility provide you all 
the details you need.

> For us, if these new TE information could not be learnt through BGP-LS, there is no interest to use them.

problem of the BGP-LS and BGP message size is a generic problem that is 
not specific to this draft and will be addressed as such.

And for sure these will come via BGP-LS.

regards,
Peter

> _______________________________________________
> Lsr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lsr
> .
>

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Fri, 24 May 2019 11:12:22 +0000

Hi Olivier, 
I think the WG's energy has been completely focused on the dynamic flooding and these WG last calls didn't get the deserved attention. 

As for as your comments, the first two were discussed for over a year and half. There were other advantages as well. For example, the link attribute encoding reduced (OSPFv2) or eliminated (OSPFv3) the need to correlate LSA attributes for a single link. We will note your objection in the shepherds report on the documents. We could even include a pointer to your quagga code that took a different approach if you wish to provide one. 

With respect to your comments on BGP-LS, this is out of scope for LSR. While I haven't seen NLRI that hits the limit, I'm confident that the IDR WG will come up with a solution. 

Thanks,
Acee

On 5/23/19, 5:57 AM, "Lsr on behalf of [email-masked]" <[email-masked] on behalf of [email-masked]> wrote:

    Dear all

    

    

    

    

    
    Regards
    
    Olivier

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 24 May 2019 14:04:43 +0200

> With respect to your comments on BGP-LS, this is out of scope for LSR.

During last IETF it has been communicated by IDR chairs that there is an
agreement that all IGP extensions in LSR WG will define in the same
document also extensions to BGP-LS so the work is not duplicated and that
IDR will stop dealing with IGP encoding.

Quote from minutes:

"Propose: one document to keep the encoding in both IGP and BGP-LS. asking
LSR to handle encoding in their document set "

Chair's slide 5:

"Propose asking LSR to handle encoding in their document set"

Putting aside to what I personally think about BGP-LS are you as LSR
co-chair not going to follow the above recommendation/proposal ?

Thx,
R.

On Fri, May 24, 2019 at 1:12 PM Acee Lindem (acee) <[email-masked]> wrote:

> Hi Olivier,
> I think the WG's energy has been completely focused on the dynamic
> flooding and these WG last calls didn't get the deserved attention.
>
> As for as your comments, the first two were discussed for over a year and
> half. There were other advantages as well. For example, the link attribute
> encoding reduced (OSPFv2) or eliminated (OSPFv3) the need to correlate LSA
> attributes for a single link. We will note your objection in the shepherds
> report on the documents. We could even include a pointer to your quagga
> code that took a different approach if you wish to provide one.
>
> With respect to your comments on BGP-LS, this is out of scope for LSR.
> While I haven't seen NLRI that hits the limit, I'm confident that the IDR
> WG will come up with a solution.
>
> Thanks,
> Acee
>
> On 5/23/19, 5:57 AM, "Lsr on behalf of [email-masked]" <
> [email-masked] on behalf of [email-masked]> 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
>     may activate or not TE information on all links of its network.
> Indeed, RFC3630 and RFC5305 precise that TE
>     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
>     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.
>
>     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
>     take time in large scale network (several weeks even several months)
> leading cohabitation of the 2 systems which
>     And finally, if we go a bit further, dealing with SDN, all these new
> TE information need to be learnt by and SDN
>     controller e.g. a PCE, which naturally conduct to use BGP-LS for this
> purpose. However, recent discussion in idr WG
>     mention that there is already too many attributes that have been
> standardised dealing with problem with the maximum
>     size of BGP message. These new TE information will also certainly
> appear as duplicate regarding RFC7752 and RFC8571.
>
>     For us, if these new TE information could not be learnt through
> BGP-LS, there is no interest to use them.
>
>     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,
>     This message and its attachments may contain confidential or
> privileged information that may be protected by law;

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Fri, 24 May 2019 12:55:15 +0000

That would be for newer documents, these documents have been long overdue with a protracted discussion. I don’t think we want to delay them anymore. Also, including the BGP-LS is somewhat dependent on the complexity. For example, it made sense to decouple SR BGP-LS encodings from the IGP drafts.

Finally, this is orthogonal to the comment on the general issue of BGP-LS possibly having NLRI that exceeds what can be sent in a single 4K BGP update.

Thanks,
Acee

From: Robert Raszuk <[email-masked]>
Date: Friday, May 24, 2019 at 8:07 AM
To: Acee Lindem <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Lsr] Summary of WGLC discussion about draft-ietf-isis-te-app-06.txt and draft-ietf-ospf-te-link-attr-reuse-07.txt

> With respect to your comments on BGP-LS, this is out of scope for LSR.

During last IETF it has been communicated by IDR chairs that there is an agreement that all IGP extensions in LSR WG will define in the same document also extensions to BGP-LS so the work is not duplicated and that IDR will stop dealing with IGP encoding.

Quote from minutes:

"Propose: one document to keep the encoding in both IGP and BGP-LS. asking LSR to handle encoding in their document set "

Chair's slide 5:

Putting aside to what I personally think about BGP-LS are you as LSR co-chair not going to follow the above recommendation/proposal ?

Thx,
R.

On Fri, May 24, 2019 at 1:12 PM Acee Lindem (acee) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Olivier,
I think the WG's energy has been completely focused on the dynamic flooding and these WG last calls didn't get the deserved attention.

Thanks,
Acee

On 5/23/19, 5:57 AM, "Lsr on behalf of [email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:

    Dear all

    Regards

    Olivier

    _______________________________________________
    Lsr mailing list
    [email-masked]<mailto:[email-masked]>
    https://www.ietf.org/mailman/listinfo/lsr

_______________________________________________
Lsr mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/lsr

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Fri, 24 May 2019 15:08:45 +0000

And…BTW…there is already a draft defining the necessary BGP-LS extensions:

https://datatracker.ietf.org/doc/draft-ketant-idr-bgp-ls-app-specific-attr/

   Les

From: Lsr <[email-masked]> On Behalf Of Acee Lindem (acee)
Sent: Friday, May 24, 2019 5:55 AM
To: Robert Raszuk <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: [Lsr] Summary of WGLC discussion about draft-ietf-isis-te-app-06.txt and draft-ietf-ospf-te-link-attr-reuse-07.txt

Thanks,
Acee

From: Robert Raszuk <[email-masked]<mailto:[email-masked]>>
Date: Friday, May 24, 2019 at 8:07 AM
To: Acee Lindem <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Lsr] Summary of WGLC discussion about draft-ietf-isis-te-app-06.txt and draft-ietf-ospf-te-link-attr-reuse-07.txt

Quote from minutes:

Chair's slide 5:

Thx,
R.

Thanks,
Acee

    Dear all

    Regards

    Olivier

---

From: <[email-masked]>
Date: Mon, 27 May 2019 16:50:33 +0200

Peter,

Please see below my answers.

Le 24/05/2019 à 12:02, Peter Psenak a écrit :
> 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.

> [ ... ]
> 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:
>

[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.

> 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)

> 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.

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 ? 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

---

From: <[email-masked]>
Date: Mon, 27 May 2019 16:59:13 +0200

Hi Acee,

Thanks to take into account my objections to the shepherds report.

For the pointer to the code, please make now reference to Free Range Routing and not Quagga.

The link is: https://github.com/FRRouting/frr and more specifically:
 - https://github.com/FRRouting/frr/lib/if.c for the link parameters implementation per interface
 - https://github.com/FRRouting/frr/ospfd/ospf_te.c for the advertisement of link parameters in OSPF
 - https://github.com/FRRouting/frr/isisd/isis_te.c for the advertisement of link parameters in ISISRegardsOlivier

---

From: Peter Psenak <[email-masked]>
Date: Mon, 27 May 2019 17:07:24 +0200

Olivier,

please see inline:

> "  This document defines extensions which address these issues."

why would it be false? What is your point?

> 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.

> [OD] Again, this is implementation specific (see above)

don't agree.

> 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.

> 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