Re: [Lsr] draft-ietf-lsr-isis-rfc5306bis-01

[Les Ginsberg (ginsberg)]

Uma –

Inline.

From: Lsr  On Behalf Of Uma Chunduri
Sent: Friday, May 24, 2019 10:49 AM
To: lsr@ietf.org
Subject: [Lsr] draft-ietf-lsr-isis-rfc5306bis-01

As asked by chairs I was trying to write the shepherd report on this doc.

Have few quick questions on this work:

1.

Observation: The new text added in 2.2.3 (PR and PA bits) is almost similar  to 
section 2.2.1 (RR and RA bits)

Now is there any relation of the timer here with T3 (which would have been set 
by restarting router with the value received with RA bit set, assuming it is 
lower than the initialized value  65535).

There is no description or guidance on how these values are related and how the 
restarting router handle this.

[Les:] The timers (T1, T2, T3) are NOT relevant to PR/PA.
PR is sent BEFORE a router does a restart to alert the neighbors that the 
signaling router’s control plane is going away for a time.

RR/RA are associated with what happens AFTER the router has restarted and now 
wants to reacquire adjacencies/LSDB.

I do not know what text in the draft suggests to you that there is any relation 
between PR/PA and RR/RA.

2.

On the text below

"a.  If additional topology changes occur, the adjacency which is in
   planned restart state MAY be brought down even though the hold
   time has not yet expired.  Given that the neighbor which has
   signaled a planned restart is not expected to update its
   forwarding plane in response to signaling of the topology changes
   (since it is restarting) traffic which transits that node is at
   risk of being improperly forwarded. "

Is this any topology change ? Not related to the restarting router in question?

Need clarification text here or point me if I miss something.


[Les:] What constitutes a topology change significant enough to trigger 
bringing down the adjacency is an implementation decision.
Definition of the conditions is NOT an interoperability issue and therefore 
does not fall within the scope of the draft.

   Les


Have few more questions/comments overall and shall come back.

--
Uma C..





___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Enhancement related to Area Leader Sub-TLV

[tony . li]

Hi Huaimo,

Thank you for your proposal.

The area leader sub-tlv is only advertised by systems that are willing to be 
area leader.  Presumably, that’s not necessarily all of the ones who support 
dynamic flooding.  Thus, what you’re proposing moves one byte from one TLV into 
another TLV that will be more commonly used. So your proposal actually consumes 
more LSP space.

The intention here is that the candidates for area leader advertise the Area 
Leader Sub-TLV.  All nodes that support dynamic flooding would advertise the 
Dynamic Flooding Sub-TLV. 
Since the priority is part of the Area Leader election, it makes sense for it 
to be part of the Area Leader Sub-TLV.

Regards,
Tony

p.s. IS-IS does not depend on word-alignment, so we typically do not leave 
reserved bytes in our TLV formats. OSPF is a different kettle of fish… :-)


> On May 24, 2019, at 1:44 PM, Huaimo Chen  wrote:
> 
> Hi Tony,
> 
>  An enhancement related to Area Leader Sub-TLV is briefed below for 
> discussions.  A .pdf file is attached in the case that the formats below are 
> messed up.
> 
> The leader of an area advertises an Area Leader Sub-TLV to indicate/instruct 
> whether centralized or distributed mode is to be used by all the nodes in the 
> area (Algorithm = 0: centralized mode; Algorithm = N (N>0): distributed mode 
> and N is the algorithm to be used by every node to compute flooding topology).
>  
> Currently for IS-IS, IS-IS Area Leader Sub-TLV below is used by each of the 
> nodes to advertise its priority for becoming the leader
> 0   1   2   3
> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>| Type  | Length| Priority  |   Algorithm   |
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>  (Current) IS-IS Area Leader Sub-TLV
>  
> It seems hard to understand that every node uses an Area Leader Sub-TLV to 
> advertise its priority for becoming the leader, and at the same time to 
> indicate/instruct whether centralized or distributed mode is to be used by 
> all the nodes in the area.
>  
> When every node advertises an Area Leader Sub-TLV, only one for 
> indication/instruction for flooding reduction mode is used, and all the 
> others are not used, which consume space and processing time.
>  
> An enhancement is to let every node advertise its priority for becoming the 
> leader and the algorithms that it supports though using a Dynamic Flooding 
> Sub-TLV, and only the leader advertise the indication for the flooding 
> reduction mode. To achieve this, some changes to the two Sub-TLVs and the 
> texts related to the Sub-TLVs should be made.
>  
> For IS-IS, IS-IS Area Leader Sub-TLV is updated as follows (Priority is 
> removed)
> 0   1   2   3
> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>| Type  | Length| Reserved  |   Algorithm   |
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>(Updated) IS-IS Area 
> Leader Sub-TLV
>  
> The Priority is added into IS-IS Dynamic Flooding Sub-TLV. The current IS-IS 
> Dynamic Flooding Sub-TLV
> 0   1   2   3
> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>| Type  | Length| Algorithm...  |
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
>(Current) IS-IS Dynamic Flooding Sub-TLV
>  
> is changed to:
> 0   1   2   3
> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>| Type  | Length| Priority   |Algorithm...  |
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
>(Updated) IS-IS Dynamic Flooding Sub-TLV
>  
> Similarly for OSPF, the current OSPF Area Leader Sub-TLV below
>0   1   2   3
>0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>   |  Type | Length|
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>   |Priority   |   Algorithm   |Reserved   |
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>(Current) OSPF Area Leader 
> Sub-TLV
> is changed to
>0   1

[Lsr] draft-ietf-lsr-isis-rfc5306bis-01

[Uma Chunduri]

As asked by chairs I was trying to write the shepherd report on this doc.

Have few quick questions on this work:

1.

Observation: The new text added in 2.2.3 (PR and PA bits) is almost similar
 to section 2.2.1 (RR and RA bits)

Now is there any relation of the timer here with T3 (which would have been
set by restarting router with the value received with RA bit set, assuming
it is lower than the initialized value  65535).

There is no description or guidance on how these values are related and how
the restarting router handle this.


2.

On the text below

"a.  If additional topology changes occur, the adjacency which is in
   planned restart state MAY be brought down even though the hold
   time has not yet expired.  Given that the neighbor which has
   signaled a planned restart is not expected to update its
   forwarding plane in response to signaling of the topology changes
   (since it is restarting) traffic which transits that node is at
   risk of being improperly forwarded. "

Is this any topology change ? Not related to the restarting router in
question?

Need clarification text here or point me if I miss something.



Have few more questions/comments overall and shall come back.

--
Uma C.
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Les Ginsberg (ginsberg)]

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  On Behalf Of Acee Lindem (acee)
Sent: Friday, May 24, 2019 5:55 AM
To: Robert Raszuk 
Cc: lsr@ietf.org; olivier.dug...@orange.com
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

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 mailto:rob...@raszuk.net>>
Date: Friday, May 24, 2019 at 8:07 AM
To: Acee Lindem mailto:a...@cisco.com>>
Cc: "olivier.dug...@orange.com" 
mailto:olivier.dug...@orange.com>>, 
"lsr@ietf.org" mailto:lsr@ietf.org>>
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:

"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) 
mailto:a...@cisco.com>> 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 
olivier.dug...@orange.com" 
mailto:lsr-boun...@ietf.org> on behalf of 
olivier.dug...@orange.com> 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 ?

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
informatio

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

[Acee Lindem (acee)]

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 
Date: Friday, May 24, 2019 at 8:07 AM
To: Acee Lindem 
Cc: "olivier.dug...@orange.com" , "lsr@ietf.org" 

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:

"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) 
mailto:a...@cisco.com>> 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 
olivier.dug...@orange.com" 
mailto:lsr-boun...@ietf.org> on behalf of 
olivier.dug...@orange.com> 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 ?

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 (sev

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

[Robert Raszuk]

> 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)  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 olivier.dug...@orange.com" <
> lsr-boun...@ietf.org on behalf of olivier.dug...@orange.com> 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 ?
>
> 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 rega

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

[Acee Lindem (acee)]

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 olivier.dug...@orange.com" 
 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 ?

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.

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]

Olivier,

please see inline:

On 23/05/2019 11:56 , olivier.dug...@orange.com 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.




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.




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


absolutely not!




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



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.




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.




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.


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




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


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




Regards

Olivier






_

Re: [Lsr] Enhancements on encoding of router IDs and DR IDs

[Peter Psenak]

Hi Huaimo,

thanks for the suggestion, I think it's good one to include.

One side effect of your proposal is that when the new ID or DR ID is 
inserted, it may cause other IDs/DR IDs to change their index, as you 
can not assume you can simply add to the end of the list anymore.


thanks,
Peter


On 23/05/2019 20:47 , Huaimo Chen wrote:

Hi Tony,


Enhancements on encoding the IDs are described below for
discussions.  A .pdf file is attached in the case that the formats below
are messed up.


Currently for OSPFv2, OSPFv2 Area Router IDs TLVs are used to represent
a sequence of router IDs or DR IDs (addresses). Each of IDs is encoded
as an OSPFv2 Router IDs TLV Entry of 8 bytes.

0   1   2   3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   |  Conn Type|Reserved   |

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   | Originating Router ID/DR Address (4 bytes)|

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 (Current) OSPFv2 Router IDs TLV Entry



To represent N router IDs or DR addresses, we need N entries, which
occupies 8*N bytes in the OSPFv2 Area Router IDs TLVs.  Each entry
represents just only one router ID or DR address.



An enhancement below is to allow one entry to represent a number of
router IDs or a number of DR addresses. This can be achieved by using
two bytes of the Reserved field to indicate the number M of router IDs
or a number of DR addresses contained in the entry.  The value of the
two bytes can be the number of IDs/Addresses (i.e., M) or the number of
octets used (i.e., 4*M). The former is preferred.



0   1   2   3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   |  Conn Type|  NumberOfIDs (M)  |   Reserved|

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   |   1st Originating Router ID/DR Address (4 bytes)  |

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   |   2nd Originating Router ID/DR Address (4 bytes)  |

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   |   |

   ~. . . . . .~

   |   |

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   |   M-th Originating Router ID/DR Address (4 bytes) |

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  (Enhanced) OSPFv2 Router IDs TLV Entry



To represent N router IDs or N DR addresses using the enhanced entry, we
need just one or a few entries. Using X entries occupies 4*(N + X) bytes
in the OSPFv2 Area Router IDs TLVs.



Consider the case where there are 1000 routers in an area. To represent
1000 router IDs,

Using the current OSPFv2 Router IDs TLV Entries occupies 8*1000 = 8000
bytes;

Using the enhanced OSPFv2 Router IDs TLV Entries occupies 4*(1000 + 1) =
4004 bytes.

8000/4004 = 1..998. The saving on space is about 50% in this case.



Similarly for OSPFv3, OSPFv3 Area Router IDs TLVs are used to represent
a sequence of router IDs or DR IDs. Each of router IDs is encoded as an
OSPFv3 Router IDs TLV Entry of 8 bytes.  Each of DR IDs is encoded as an
OSPFv3 Router IDs TLV Entry of 12 bytes.



   0   1   2   3

   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  |  Conn Type|  Reserved |

  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  |Originating Router ID (always present) |

  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  |Interface ID (present for DRs) |

  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 (Current) OSPFv3 Router IDs TLV Entry



An enhancement below is to allow one entry to represent a number of
router IDs or a number of DR IDs. This can be achieved by using two
bytes of the Reserved field to indicate the number M of router IDs or a
number of DR IDs contained in the entry.  The value of the two bytes can
be the number of IDs (i.e., M) or the number of octets used (i.e., 4*M
for M router IDs or 8*M for M DR IDs). The former is preferred.



   0   1   2