Re: [Lsr] RFC 8919, RFC 8920, Flex Algo, and Flex Algo BW Constraints

[Robert Raszuk]

Hi Ron,

So here is the suggestion ...

Currently the encoded values of SABM are:

   SABM (variable length):  Standard Application Identifier Bit Mask
  (SABM Length * 8) bits
  This field is omitted if SABM Length is 0.

0 1 2 3 4 5 6 7 ...
   +-+-+-+-+-+-+-+-+...
   |R|S|F|X|...
   +-+-+-+-+-+-+-+-+...

R-bit:  Set to specify RSVP-TE.
S-bit:  Set to specify Segment Routing Policy.
F-bit:  Set to specify Loop-Free Alternate (LFA) (includes all LFA
types).
X-bit: Set to specify Flexible Algorithm

How about you write a one page draft to specify bit #4

* A-bit: Set to specify all applications - current and future. *

I am not sure if this is really needed (as one could easily just set all
bits R, S F  to 1, but maybe when we have 1000 applications and you
have a metric which should apply to all of them you just would be better to
set A-bit and be done ?

On another note as mentioned before I do agree with Shraddha about Flex
Algo just using one bit is not enough. If I run two or N topologies each
should have its own bit. At least SABM should define few for flex algo and
if more is needed we go to UDABM.

Best,
Robert


On Tue, Aug 17, 2021 at 9:58 PM Ron Bonica  wrote:

> Robert,
>
>
>
> The following information types need to be distributed :
>
>
>
>1. Application Independent Link Attributes
>   1. Mentioned in Section 3.2 of RFC 8919
>   2. Not mentioned in Section 3.2 of RFC 8919
>2. Application Configuration Information that is associated with an
>interface
>3. Application Information that is not associated with an interface
>
>
>
> Section 6.1 of RFC 8919 addresses information of Type 1a). Under some
> conditions, it can be advertised as described in RFC 5305. In other
> conditions, it must be advertised as ASLA.
>
>
>
> Information of Type 1b) should by advertised as were the TE attributes
> defined in RFC 5305 (i.e., outside of the ASLA context).
>
>
>
> Information of Type 2 should be advertises as ASLA.
>
>
>
> Information of Type 3 should be considered on an application by
> application basis. For Flexalgo, it should be advertised in the FAD.
>
>
>
>
>   
>Ron
>
>
>
>
>
> Juniper Business Use Only
>
> *From:* Robert Raszuk 
> *Sent:* Tuesday, August 17, 2021 2:52 PM
> *To:* Ron Bonica 
> *Cc:* Acee Lindem (acee) ; lsr@ietf.org
> *Subject:* Re: [Lsr] RFC 8919, RFC 8920, Flex Algo, and Flex Algo BW
> Constraints
>
>
>
> *[External Email. Be cautious of content]*
>
>
>
> Hi Ron,
>
>
>
> Please kindly enlighten me on your line of thinking ...
>
>
>
> Let's consider your list:
>
>
>
> Total physical bandwidth
> Number of LAG elements
> Bandwidth of smallest lag member
> Latency
>
>
>
> Then as a method of distributing them you choose your option 3 which
> reads:
>
>
>
> "Configure this information in a few central places and advertise it to
> all other nodes. The advertisement is not associated with a link. Flexalgo
> uses the FAD in this manner."
>
>
>
> Question:
>
>
>
> How can you configure any of the metrics you enumerated "in a few central
> places" irrespective on how we encode it in IGP ?  Isn't each of those
> properties local to each node which needs to be flooded via a domain from
> each node ?
>
>
>
> Thx,
>
> R.
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Tue, Aug 17, 2021 at 8:20 PM Ron Bonica  40juniper@dmarc.ietf.org> wrote:
>
> Acee,
>
>
>
> So, let us discuss whether there is a good reason for
> draft-ietf-lsr-flex-algo-con to specify ASLA !
>
>
>
> Link attributes are different from application configuration information.
> Link attributes are properties of a link.  They are independent of the
> applications that use them. The following are examples:
>
>
>
>- Total physical bandwidth
>- Number of LAG elements
>- Bandwidth of smallest lag member
>- Latency
>
>
>
> Link attributes do not benefit from ASLA encoding because they are not
> application specific.
>
>
>
> Application configuration information constrains the behavior of an
> application. It can apply to:
>
>
>
>- The application and a link
>- The application only
>
>
>
> Bandwidth reservation applies to an application and a link. For example, a
> link may advertise that it has:
>
>
>
>- X Gbps available for RSVP-TE reservations
>- Y Gbps available for SR Policy reservations
>- Z Gbps available for TI-LFA reservations
>
>
>
> This class of configuration information clearly benefits from ASLA
> encoding, because it is applicable to both the application and the link.
>
>
>
> Some applications (e.g., Flexalgo) can be configured to use a variety of
> link attributes in SPF calculation. No matter how they acquire this
> configuration information, it MUST be the same at each node. Otherwise,
> routing loops may result. Configuration options are:
>
>
>
>1. Configure this information on each

Re: [Lsr] RFC 8919, RFC 8920, Flex Algo, and Flex Algo BW Constraints

[Ron Bonica]

Robert,

The following information types need to be distributed :


  1.  Application Independent Link Attributes
 *   Mentioned in Section 3.2 of RFC 8919
 *   Not mentioned in Section 3.2 of RFC 8919
  2.  Application Configuration Information that is associated with an interface
  3.  Application Information that is not associated with an interface

Section 6.1 of RFC 8919 addresses information of Type 1a). Under some 
conditions, it can be advertised as described in RFC 5305. In other conditions, 
it must be advertised as ASLA.

Information of Type 1b) should by advertised as were the TE attributes defined 
in RFC 5305 (i.e., outside of the ASLA context).

Information of Type 2 should be advertises as ASLA.

Information of Type 3 should be considered on an application by application 
basis. For Flexalgo, it should be advertised in the FAD.


 Ron



Juniper Business Use Only
From: Robert Raszuk 
Sent: Tuesday, August 17, 2021 2:52 PM
To: Ron Bonica 
Cc: Acee Lindem (acee) ; lsr@ietf.org
Subject: Re: [Lsr] RFC 8919, RFC 8920, Flex Algo, and Flex Algo BW Constraints

[External Email. Be cautious of content]

Hi Ron,

Please kindly enlighten me on your line of thinking ...

Let's consider your list:

Total physical bandwidth
Number of LAG elements
Bandwidth of smallest lag member
Latency

Then as a method of distributing them you choose your option 3 which reads:

"Configure this information in a few central places and advertise it to all 
other nodes. The advertisement is not associated with a link. Flexalgo uses the 
FAD in this manner."

Question:

How can you configure any of the metrics you enumerated "in a few central 
places" irrespective on how we encode it in IGP ?  Isn't each of those 
properties local to each node which needs to be flooded via a domain from each 
node ?

Thx,
R.






On Tue, Aug 17, 2021 at 8:20 PM Ron Bonica 
mailto:40juniper@dmarc.ietf.org>> 
wrote:
Acee,

So, let us discuss whether there is a good reason for 
draft-ietf-lsr-flex-algo-con to specify ASLA !

Link attributes are different from application configuration information. Link 
attributes are properties of a link.  They are independent of the applications 
that use them. The following are examples:


  *   Total physical bandwidth
  *   Number of LAG elements
  *   Bandwidth of smallest lag member
  *   Latency

Link attributes do not benefit from ASLA encoding because they are not 
application specific.

Application configuration information constrains the behavior of an 
application. It can apply to:


  *   The application and a link
  *   The application only

Bandwidth reservation applies to an application and a link. For example, a link 
may advertise that it has:


  *   X Gbps available for RSVP-TE reservations
  *   Y Gbps available for SR Policy reservations
  *   Z Gbps available for TI-LFA reservations

This class of configuration information clearly benefits from ASLA encoding, 
because it is applicable to both the application and the link.

Some applications (e.g., Flexalgo) can be configured to use a variety of link 
attributes in SPF calculation. No matter how they acquire this configuration 
information, it MUST be the same at each node. Otherwise, routing loops may 
result. Configuration options are:


  1.  Configure this information on each link and advertise link attributes 
with ASLA
  2.  Configure this information on each node that runs the application
  3.  Configure this information in a few central places and advertise it to 
all other nodes. The advertisement is not associated with a link. Flexalgo uses 
the FAD in this manner.

Neither Option 1 nor Option 2 is very appealing, because it requires 
configuration on each node. Option 3 is better because:


  *   It requires configuration on only a few nodes
  *   It maintains separation between link attributes and application 
configuration information
  *   It can support applications like Flexalgo, where each algorithm may use 
different link attributes to calculate the shortest path


Ron





Juniper Business Use Only
From: Acee Lindem (acee) 
mailto:40cisco@dmarc.ietf.org>>
Sent: Friday, August 13, 2021 10:22 AM
To: Ron Bonica mailto:rbon...@juniper.net>>; 
lsr@ietf.org
Subject: Re: [Lsr] RFC 8919, RFC 8920, Flex Algo, and Flex Algo BW Constraints

[External Email. Be cautious of content]

Speaking as a WG member:

Hi Ron,
My rationale is #1. The LSR WG developed ASLAs to cover usage of the link 
attributes (including metrics) for different applications and mitigate all the 
vagaries of the original TE link attribute specifications. ASLAs are 
implemented and deployed. I believe it would be a mistake to bifurcate the IGP 
standards with yet another way of encoding link attributes for different 
a

Re: [Lsr] RFC 8919, RFC 8920, Flex Algo, and Flex Algo BW Constraints

[Robert Raszuk]

Hi Ron,

Please kindly enlighten me on your line of thinking ...

Let's consider your list:

Total physical bandwidth
Number of LAG elements
Bandwidth of smallest lag member
Latency

Then as a method of distributing them you choose your option 3 which reads:

"Configure this information in a few central places and advertise it to all
other nodes. The advertisement is not associated with a link. Flexalgo uses
the FAD in this manner."

Question:

How can you configure any of the metrics you enumerated "in a few central
places" irrespective on how we encode it in IGP ?  Isn't each of those
properties local to each node which needs to be flooded via a domain from
each node ?

Thx,
R.






On Tue, Aug 17, 2021 at 8:20 PM Ron Bonica  wrote:

> Acee,
>
>
>
> So, let us discuss whether there is a good reason for
> draft-ietf-lsr-flex-algo-con to specify ASLA !
>
>
>
> Link attributes are different from application configuration information.
> Link attributes are properties of a link.  They are independent of the
> applications that use them. The following are examples:
>
>
>
>- Total physical bandwidth
>- Number of LAG elements
>- Bandwidth of smallest lag member
>- Latency
>
>
>
> Link attributes do not benefit from ASLA encoding because they are not
> application specific.
>
>
>
> Application configuration information constrains the behavior of an
> application. It can apply to:
>
>
>
>- The application and a link
>- The application only
>
>
>
> Bandwidth reservation applies to an application and a link. For example, a
> link may advertise that it has:
>
>
>
>- X Gbps available for RSVP-TE reservations
>- Y Gbps available for SR Policy reservations
>- Z Gbps available for TI-LFA reservations
>
>
>
> This class of configuration information clearly benefits from ASLA
> encoding, because it is applicable to both the application and the link.
>
>
>
> Some applications (e.g., Flexalgo) can be configured to use a variety of
> link attributes in SPF calculation. No matter how they acquire this
> configuration information, it MUST be the same at each node. Otherwise,
> routing loops may result. Configuration options are:
>
>
>
>1. Configure this information on each link and advertise link
>attributes with ASLA
>2. Configure this information on each node that runs the application
>3. Configure this information in a few central places and advertise it
>to all other nodes. The advertisement is not associated with a link.
>Flexalgo uses the FAD in this manner.
>
>
>
> Neither Option 1 nor Option 2 is very appealing, because it requires
> configuration on each node. Option 3 is better because:
>
>
>
>- It requires configuration on only a few nodes
>- It maintains separation between link attributes and application
>configuration information
>- It can support applications like Flexalgo, where each algorithm may
>use different link attributes to calculate the shortest path
>
>
>
>
>   Ron
>
>
>
>
>
>
>
>
>
> Juniper Business Use Only
>
> *From:* Acee Lindem (acee) 
> *Sent:* Friday, August 13, 2021 10:22 AM
> *To:* Ron Bonica ; lsr@ietf.org
> *Subject:* Re: [Lsr] RFC 8919, RFC 8920, Flex Algo, and Flex Algo BW
> Constraints
>
>
>
> *[External Email. Be cautious of content]*
>
>
>
> Speaking as a WG member:
>
>
>
> Hi Ron,
>
> My rationale is #1. The LSR WG developed ASLAs to cover usage of the link
> attributes (including metrics) for different applications and mitigate all
> the vagaries of the original TE link attribute specifications. ASLAs are
> implemented and deployed. I believe it would be a mistake to bifurcate the
> IGP standards with yet another way of encoding link attributes for
> different applications.
>
> Thanks,
>
> Acee
>
>
>
> *From: *Lsr  on behalf of Ron Bonica <
> rbonica=40juniper@dmarc.ietf.org>
> *Date: *Thursday, August 12, 2021 at 3:46 PM
> *To: *"Acee Lindem (acee)" , "
> lsr@ietf.org" 
> *Subject: *Re: [Lsr] RFC 8919, RFC 8920, Flex Algo, and Flex Algo BW
> Constraints
>
>
>
> Acee,
>
>
>
> Please help me to parse your message. It is clear that you want
> draft-ietf-lsr-flex-algo-bw-con to specify ASLA’s. However, your rationale
> is not so clear.
>
>
>
> It is not because RFC 8919 mandates ASLA. In fact, we agree that it would
> be strange for an RFC to include a mandate that precludes future proposals.
>
>
>
> Are any of the following your rationale:
>
>
>
> 1) Because there is a good technical reason for
> draft-ietf-lsr-flex-algo-bw-con to specify ASLA
>
> 2) Because it is possible, but not necessary, for
> draft-ietf-lsr-flex-algo-bw-con to specify ASLA
>
> 3) Because it was the unstated intention of RFC 8919 to include a
> mandate that precludes future proposals (although we agree that this would
> be strange).
>
>
>
> For the purposes of full disclosure, I think discussion regarding the
> first rationale would be fruitful. However, I don’t think very much of the
> second or third ra

Re: [Lsr] RFC 8919, RFC 8920, Flex Algo, and Flex Algo BW Constraints

[Ron Bonica]

Acee,

So, let us discuss whether there is a good reason for 
draft-ietf-lsr-flex-algo-con to specify ASLA !

Link attributes are different from application configuration information. Link 
attributes are properties of a link.  They are independent of the applications 
that use them. The following are examples:


  *   Total physical bandwidth
  *   Number of LAG elements
  *   Bandwidth of smallest lag member
  *   Latency

Link attributes do not benefit from ASLA encoding because they are not 
application specific.

Application configuration information constrains the behavior of an 
application. It can apply to:


  *   The application and a link
  *   The application only

Bandwidth reservation applies to an application and a link. For example, a link 
may advertise that it has:


  *   X Gbps available for RSVP-TE reservations
  *   Y Gbps available for SR Policy reservations
  *   Z Gbps available for TI-LFA reservations

This class of configuration information clearly benefits from ASLA encoding, 
because it is applicable to both the application and the link.

Some applications (e.g., Flexalgo) can be configured to use a variety of link 
attributes in SPF calculation. No matter how they acquire this configuration 
information, it MUST be the same at each node. Otherwise, routing loops may 
result. Configuration options are:


  1.  Configure this information on each link and advertise link attributes 
with ASLA
  2.  Configure this information on each node that runs the application
  3.  Configure this information in a few central places and advertise it to 
all other nodes. The advertisement is not associated with a link. Flexalgo uses 
the FAD in this manner.

Neither Option 1 nor Option 2 is very appealing, because it requires 
configuration on each node. Option 3 is better because:


  *   It requires configuration on only a few nodes
  *   It maintains separation between link attributes and application 
configuration information
  *   It can support applications like Flexalgo, where each algorithm may use 
different link attributes to calculate the shortest path


Ron





Juniper Business Use Only
From: Acee Lindem (acee) 
Sent: Friday, August 13, 2021 10:22 AM
To: Ron Bonica ; lsr@ietf.org
Subject: Re: [Lsr] RFC 8919, RFC 8920, Flex Algo, and Flex Algo BW Constraints

[External Email. Be cautious of content]

Speaking as a WG member:

Hi Ron,
My rationale is #1. The LSR WG developed ASLAs to cover usage of the link 
attributes (including metrics) for different applications and mitigate all the 
vagaries of the original TE link attribute specifications. ASLAs are 
implemented and deployed. I believe it would be a mistake to bifurcate the IGP 
standards with yet another way of encoding link attributes for different 
applications.
Thanks,
Acee

From: Lsr mailto:lsr-boun...@ietf.org>> on behalf of Ron 
Bonica 
mailto:rbonica=40juniper@dmarc.ietf.org>>
Date: Thursday, August 12, 2021 at 3:46 PM
To: "Acee Lindem (acee)" 
mailto:acee=40cisco@dmarc.ietf.org>>, 
"lsr@ietf.org" mailto:lsr@ietf.org>>
Subject: Re: [Lsr] RFC 8919, RFC 8920, Flex Algo, and Flex Algo BW Constraints

Acee,

Please help me to parse your message. It is clear that you want 
draft-ietf-lsr-flex-algo-bw-con to specify ASLA's. However, your rationale is 
not so clear.

It is not because RFC 8919 mandates ASLA. In fact, we agree that it would be 
strange for an RFC to include a mandate that precludes future proposals.

Are any of the following your rationale:


1) Because there is a good technical reason for 
draft-ietf-lsr-flex-algo-bw-con to specify ASLA

2) Because it is possible, but not necessary, for 
draft-ietf-lsr-flex-algo-bw-con to specify ASLA

3) Because it was the unstated intention of RFC 8919 to include a mandate 
that precludes future proposals (although we agree that this would be strange).

For the purposes of full disclosure, I think discussion regarding the first 
rationale would be fruitful. However, I don't think very much of the second or 
third rationale.


Ron





Juniper Business Use Only
From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of Acee 
Lindem (acee)
Sent: Tuesday, August 10, 2021 4:43 PM
To: lsr@ietf.org
Subject: [Lsr] RFC 8919, RFC 8920, Flex Algo, and Flex Algo BW Constraints

[External Email. Be cautious of content]

Speaking as a WG Member:

  In reviewing RFC 8919 and RFC 8920, it is clear that the ASLA mechanism was 
to be used for new link attributes and applications. While the documents do not 
mandate that there never could be a new way to advertise link attributes, this 
was clearly the intent. Indeed, it would be strange for an RFC to include a 
mandate that precluded future 

Re: [Lsr] Generic metric: application-specific vs application-independent

[Shraddha Hegde]

Peter,

>no, I don't want to use affinities to do that. That's the whole point.
>ASLA gives you per link per application signaling. No need to use affinities.

The usecase you are describing to exclude links from an application topology is 
very straight 
forward and how this is done is defined by applications.
TE applications have defined a topology filter data model that uses 
link-affinities to Include/exclude links from topology 
 
https://datatracker.ietf.org/doc/html/draft-bestbar-teas-yang-topology-filter-00.
 
 In your example if application B is any TE application it would be natural to 
use link-affinities.

If application B is LFA, RFC 7916 defines link-coloring and include exclude 
policies to be used (Refer sec 6.2.3).
so it cannot use application bits on metric to exclude links.

If we assume application A and B are both Flex-algos, ASLA  
natively doesn't support Per flex-algo attribute advertisement 
and it is extremely complex to define user-defined bit masks for Each 
flex-algo and assign the bit masks on the metric on every router. 
Operator could use link-affinities to Exclude links 
from flex-algo topology which is much simpler.

Rgds
Shraddha


Juniper Business Use Only

-Original Message-
From: Peter Psenak  
Sent: Saturday, July 31, 2021 1:07 AM
To: Shraddha Hegde ; Robert Raszuk ; 
Van De Velde, Gunter (Nokia - BE/Antwerp) 
Cc: Les Ginsberg (ginsberg) ; Tony Li ; 
lsr@ietf.org
Subject: Re: [Lsr] Generic metric: application-specific vs 
application-independent

[External Email. Be cautious of content]


Shraddha,

On 30/07/2021 18:45, Shraddha Hegde wrote:
> Peter,
>
>> imagine you have an application A and B and a link X. You advertise 
>> application independent metric M on that link X >because you want 
>> application A to use it.
>
>> Application B is also enabled to use the metric M, but you do not want 
>> application B to use metric M on the link X >(because you do not want 
>> application B to include the link X in its topology). How do you do that 
>> without ASLA? The >answer is you can't.
>
> This is very straight forward to do without ASLA.
>   I would define an admin-group and assign that admin group on link X and
>   exclude that admin-group from Application B.
>   This is much common way how
>   operators exclude links from the topology.

no, I don't want to use affinities to do that. That's the whole point.
ASLA gives you per link per application signaling. No need to use affinities.

>
>   The alternative being proposed with ASLA is much more fragile.
>   An operator would have to set the bits for application A and Application B
>   for metric M on every link that he wants to include and reset the
>   application bit B on links that he wants to exclude for application B.

sorry, but setting affinities is not any easier, so the above argument is not 
valid.


Peter



>   Imagine what would happen if he missed setting the bit or resetting
>   the bit on some of the links and how difficult it would be to debug.
>
> Rgds
> Shraddha
>
>
> Juniper Business Use Only
>
> -Original Message-
> From: Peter Psenak 
> Sent: Friday, July 30, 2021 7:09 PM
> To: Shraddha Hegde ; Robert Raszuk 
> ; Van De Velde, Gunter (Nokia - BE/Antwerp) 
> 
> Cc: Les Ginsberg (ginsberg) ; Tony Li 
> ; lsr@ietf.org
> Subject: Re: [Lsr] Generic metric: application-specific vs 
> application-independent
>
> [External Email. Be cautious of content]
>
>
> Shraddha,
>
>
> On 30/07/2021 15:22, Shraddha Hegde wrote:
>> Robert,
>>
>>   > Can anyone explain how do I map generic metric to selected 
>> network applications I am to run in the network ?
>>
>> Which application uses which metric type is defined by the application.
>
> imagine you have an application A and B and a link X. You advertise 
> application independent metric M on that link X because you want application 
> A to use it.
>
> Application B is also enabled to use the metric M, but you do not want 
> application B to use metric M on the link X (because you do not want 
> application B to include the link X in its topology). How do you do that 
> without ASLA? The answer is you can't.
>
> thanks,
> Peter
>
>>
>> For example in flex-algo FAD defines which metric-type its going to use.
>>
>> In SR-TE, the constraint list specifies which metric-type it is going 
>> to use.
>>
>> Rgds
>>
>> Shraddha
>>
>> Juniper Business Use Only
>>
>> *From:* Robert Raszuk 
>> *Sent:* Friday, July 30, 2021 6:20 PM
>> *To:* Van De Velde, Gunter (Nokia - BE/Antwerp) 
>> 
>> *Cc:* Peter Psenak ; Shraddha Hegde 
>> ; Les Ginsberg (ginsberg) ; 
>> Tony Li ; lsr@ietf.org
>> *Subject:* Re: [Lsr] Generic metric: application-specific vs 
>> application-independent
>>
>> *[External Email. Be cautious of content]*
>>
>> Hey Gunter,
>>
>>   > It doesn’t make sense to have Application specific values if a 
>> particular metric is obtained only dynamically,
>>
>> It sure does.
>>
>> Please notice what ASLA RFCs say up front in the abstract. ASLA is 
>> use

Re: [Lsr] [Stub-Link-Attributes] Comments on "Passive Interface Attribute" - draft-wang-lsr-passive-interface-attribute

[Acee Lindem (acee)]

Hi Aijun,
I think that would be an excellent idea.
Thanks,
Acee

From: Aijun Wang 
Date: Monday, August 16, 2021 at 9:17 PM
To: Acee Lindem 
Cc: 'Aijun Wang' , 'Gyan Mishra' 
, "draft-wang-lsr-passive-interface-attrib...@ietf.org" 
, "lsr@ietf.org" 

Subject: RE: [Lsr] [Stub-Link-Attributes] Comments on "Passive Interface 
Attribute" - draft-wang-lsr-passive-interface-attribute

Hi, Acee:

How about the following considerations:

1. For OSPFv2/v3, we can put the proposed TLVs within in “Inter-AS-TE-v2/v3 
LSA”(for OSPFv2/v3) as defined in RFC5392.

2. For ISIS, we can put them under “Inter-AS Reachability TLV”, as defined 
in RFC5316.
Comparing with other proposals, the above solutions may be more easy to 
implement and deployment, and does not influence the core SPF computation.

Best Regards

Aijun Wang
China Telecom

From: Acee Lindem (acee) 
Sent: Tuesday, August 17, 2021 4:15 AM
To: Aijun Wang 
Cc: Aijun Wang ; Gyan Mishra ; 
draft-wang-lsr-passive-interface-attrib...@ietf.org; lsr@ietf.org
Subject: Re: [Lsr] [Stub-Link-Attributes] Comments on "Passive Interface 
Attribute" - draft-wang-lsr-passive-interface-attribute

Hi Aijun,

From: Aijun Wang mailto:wangai...@tsinghua.org.cn>>
Date: Sunday, August 15, 2021 at 12:17 AM
To: Acee Lindem mailto:a...@cisco.com>>
Cc: Aijun Wang mailto:wang...@chinatelecom.cn>>, Gyan 
Mishra mailto:hayabusa...@gmail.com>>, 
"draft-wang-lsr-passive-interface-attrib...@ietf.org"
 
mailto:draft-wang-lsr-passive-interface-attrib...@ietf.org>>,
 "lsr@ietf.org" mailto:lsr@ietf.org>>
Subject: Re: [Lsr] [Stub-Link-Attributes] Comments on "Passive Interface 
Attribute" - draft-wang-lsr-passive-interface-attribute

Hi, Acee:

The information that we want to distribute are the attributes of the stub link, 
not the associated prefixes. The associated prefix is just one attributes of 
them.
The Stub-Link TLV proposed in this draft is different from the normal Link TLV. 
It will and should not influence the core SPF calculation, whose aim is 
protocol independent.
When router receive these Stub-Link TLVs, which are in the Router LSA, they 
should only use it for cases mentioned in this draft, or other applications 
that differ from the SPF calculations. I think such considerations does not 
conflict with the purpose of RFC5340.

Or, we can consider this issue from other viewpoints: there are emerging 
applications that needs to use the characters of these stub-links, we should 
re-examine the design considerations made in 14 years ago.

And, for OSPFv2/v3, there are some ways to correlate the stub link interface 
and its associated prefixes(via the interface ID) if we do not put them 
together. But for ISIS, I do not find the correlation method. For consistency 
and simplicity, I propose to keep the current encoding format.

It is also a bit strange that let the attributes(for example, bandwidth, delay, 
 reserved resources etc.) associated with the prefixes, and at current there is 
no solution if different applications want to define different values for these 
attributes(ASLA).  Will we define ASPA(Application Specified Prefixes 
Attributes) then?

If you are proposing to advertise links and their attributes for links that are 
outside of the IGP topology, you should not advertise them with the same OSPF 
LSAs or IS-IS TLVs as the links that have meaning to the IGPs. Also, this would 
beg the question as to why you are not using IS-IS Gen App (RFC 6823) and OSPF 
Transport Instance to advertise this information. If this is where you are 
going, I don’t believe you have a strong enough use case to justify 
specification, let alone the development and deployment.

Thanks,
Acee





Aijun Wang
China Telecom

On Aug 15, 2021, at 03:24, Acee Lindem (acee) 
mailto:a...@cisco.com>> wrote:
Speaking as WG Member and longstanding steward of the OSPF protocol:

Hi Aijun,

As I stated during the LSR meeting, one of the main changes between OSPFv3 and 
OSPFv2 is that the addressing semantics are removed from the router and network 
LSAs. Refer to section 2.2 in RFC 5340.

  o  Router-LSAs and network-LSAs no longer contain network addresses,
  but simply express topology information.  See Section 2.8 for
  details.

The OSPFv2 stub link was somewhat of a hack to advertise local prefixes and it 
was removed in OSPFv3 as prefixes are advertised in separate LSAs. We certainly 
don’t want to revert this behavior and definitely not for a questionable use 
case outside the OSPF protocol itself.

Additionally, the example you state of the prefixes already being advertised 
ambiguously is not flawed in the that the Link-LSA and Intra-area-prefix-LSA 
are advertised at different flooding scopes (link-scope versus area-scope).

The attributes that you want to convey throughout the area domain are relevant 
to the prefix itself and not a link that has any topological significance to 
OSPF. This sho

Re: [Lsr] LSR WG Adoption Call for SRv6 YANG drafts

[Acee Lindem (acee)]

The WG Adoption call has ended and there is sufficient support for WG adoption. 
Please republish the drafts as:

draft-ietf-lsr-isis-srv6-yang-00.txt
draft-ietf-lsr-ospf-srv6-yang-00.txt 

Note that the IS-IS draft name should also include "lsr-". 

Thanks,
Chris and Acee

On 7/22/21, 6:50 AM, "Christian Hopps"  wrote:


Hi Folks,

This begins a 3 week WG Adoption Call for the following related YANG drafts:

https://datatracker.ietf.org/doc/draft-hu-isis-srv6-yang/
https://datatracker.ietf.org/doc/draft-hu-lsr-ospf-srv6-yang/

Please indicate your support or objections by August 12th, 2021

Authors, please respond to the list indicating whether you are aware of any 
IPR that applies to these drafts.

Thanks,
Chris.

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

[Lsr] IPR Declarations for SRv6 YANG drafts

[Acee Lindem (acee)]

We still need IPR declarations from Kamran Raza and Dan Ye.

Thanks,
Chris and Acee

On 7/22/21, 6:50 AM, "Christian Hopps"  wrote:


Hi Folks,

This begins a 3 week WG Adoption Call for the following related YANG drafts:

https://datatracker.ietf.org/doc/draft-hu-isis-srv6-yang/
https://datatracker.ietf.org/doc/draft-hu-lsr-ospf-srv6-yang/

Please indicate your support or objections by August 12th, 2021

Authors, please respond to the list indicating whether you are aware of any 
IPR that applies to these drafts.

Thanks,
Chris.

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

Re: [Lsr] Secdir last call review of draft-ietf-lsr-pce-discovery-security-support-05

[Qin Wu]

Thanks Yaron.

-Qin
-邮件原件-
发件人: Yaron Sheffer [mailto:yaronf.i...@gmail.com] 
发送时间: 2021年8月17日 15:15
收件人: Qin Wu ; Acee Lindem (acee) ; tom 
petch ; sec...@ietf.org
抄送: draft-ietf-lsr-pce-discovery-security-support@ietf.org
主题: Re: Secdir last call review of 
draft-ietf-lsr-pce-discovery-security-support-05

Looks good to me. Thank you!

Yaron

On 8/17/21, 03:17, "Qin Wu"  wrote:

Sorry for late followup, here is the update, the diff is

https://www.ietf.org/rfcdiff?url2=draft-ietf-lsr-pce-discovery-security-support-06
Yaron, let authors know if your comments are addressed in v-06.
Thanks!

-Qin
-邮件原件-
发件人: Acee Lindem (acee) [mailto:a...@cisco.com] 
发送时间: 2021年8月17日 4:33
收件人: Qin Wu ; tom petch ; Yaron 
Sheffer ; sec...@ietf.org
抄送: draft-ietf-lsr-pce-discovery-security-support@ietf.org
主题: Re: Secdir last call review of 
draft-ietf-lsr-pce-discovery-security-support-05

Hi Qin, 

Can you publish a revision so that Yaron assure it satisfies his comments? 

Thanks,
Acee

On 8/12/21, 9:21 PM, "Qin Wu"  wrote:

Thanks Acee and Tom for good suggestion, we will take them into account.

-Qin
-邮件原件-
发件人: Acee Lindem (acee) [mailto:a...@cisco.com] 
发送时间: 2021年8月12日 1:18
收件人: tom petch ; Yaron Sheffer 
; Qin Wu ; sec...@ietf.org
抄送: draft-ietf-lsr-pce-discovery-security-support@ietf.org
主题: Re: Secdir last call review of 
draft-ietf-lsr-pce-discovery-security-support-05

I'd also recommend changing, "key names" to "key-ids or key-chain 
names" since this is what is actually being advertised.
Thanks,
Acee

On 8/10/21, 11:53 AM, "tom petch"  wrote:

From: Lsr  on behalf of Yaron Sheffer 

Sent: 10 August 2021 14:57

So let me suggest:


An offlist suggestion for you to consider

OLD
Thus before advertisement of the PCE security parameters, it 
MUST be insured that the IGP protects the authentication and integrity of the 
PCED TLV using the mechanisms defined in
[RFC5310] and [RFC5709], if the mechanism described in this 
document is used.

Moreover, as stated in [RFC5088] and [RFC5089], the IGP do not 
provide any encryption mechanisms to protect the secrecy of the PCED TLV, and 
the operator must ensure that no private data is carried in the TLV, for 
example that key names do not reveal sensitive information about the network.

NEW

 Thus before advertising the PCE security parameters, using the 
mechanism described in this document, the IGP MUST be known to provide 
authentication and integrity for the PCED TLV using the mechanisms defined in  
[RFC5304],  [RFC5310] or [RFC5709],

Moreover, as stated in [RFC5088] and [RFC5089], if the IGP does 
not provide any encryption mechanisms to protect the secrecy of the PCED TLV, 
then the operator must ensure that no private data is carried in the TLV, e.g. 
that key names do not reveal sensitive information about the network.

Tom Petch


Thanks,
Yaron

On 8/10/21, 15:01, "Qin Wu"  wrote:

Yaron:
Thank for clarification. I agree to keep the last sentence in 
the second paragraph of section 7 as is.
But I prefer to add the addition references in the previous 
sentence as follows:
"
Thus before advertisement of the PCE security parameters, it 
MUST be insured that the IGP is
protected for authentication and integrity of the PCED TLV,, 
with the mechanisms defined in
[RFC5310] and [RFC5709] if the mechanism described in this 
document is used.

As stated in [RFC5088] and [RFC5089], the IGP do not provide 
encryption mechanism to protect
the privacy of the PCED TLV, if this information can make the 
PCEP session less secure then the operator should take that into consideration.
"
If you better wording, please let me know.

-Qin
-邮件原件-
发件人: Yaron Sheffer [mailto:yaronf.i...@gmail.com]
发送时间: 2021年8月10日 19:26
收件人: Qin Wu ; sec...@ietf.org
抄送: draft-ietf-lsr-pce-discovery-security-support@ietf.org; 
last-c...@ietf.org; lsr@ietf.org
主题: Re: Secdir last call review of 
draft-ietf-lsr-pce-discovery-security-support-05

Hi Qin,

Sorry, but I find your latest proposed text very confusing, 
because we should be focusing on integrity protection and not privacy 
(=secrecy) of the TLV. So I would prefer to keep the text as-is, with the 
addition of a reference to the IS-IS and OSPF security mechanisms that were 
discussed on this threa

[Lsr] I-D Action: draft-ietf-lsr-pce-discovery-security-support-07.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Link State Routing WG of the IETF.

Title   : IGP extension for PCEP security capability support in 
the PCE discovery
Authors : Diego R. Lopez
  Qin Wu
  Dhruv Dhody
  Qiufang Ma
  Daniel King
Filename: draft-ietf-lsr-pce-discovery-security-support-07.txt
Pages   : 10
Date: 2021-08-17

Abstract:
   When a Path Computation Element (PCE) is a Label Switching Router
   (LSR) participating in the Interior Gateway Protocol (IGP), or even a
   server participating in IGP, its presence and path computation
   capabilities can be advertised using IGP flooding.  The IGP
   extensions for PCE discovery (RFC 5088 and RFC 5089) define a method
   to advertise path computation capabilities using IGP flooding for
   OSPF and IS-IS respectively.  However these specifications lack a
   method to advertise PCEP security (e.g., Transport Layer Security
   (TLS), TCP Authentication Option (TCP-AO)) support capability.

   This document defines capability flag bits for PCE-CAP-FLAGS sub-TLV
   that can be announced as an attribute in the IGP advertisement to
   distribute PCEP security support information.  In addition, this
   document updates RFC 5088 and RFC 5089 to allow advertisement of Key
   ID or Key Chain Name Sub-TLV to support TCP-AO security capability.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-lsr-pce-discovery-security-support/

There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-pce-discovery-security-support-07

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-lsr-pce-discovery-security-support-07


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


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

[Lsr] New Version Notification - draft-ietf-lsr-pce-discovery-security-support-07.txt

[internet-drafts]

A new version (-07) has been submitted for 
draft-ietf-lsr-pce-discovery-security-support:
https://www.ietf.org/archive/id/draft-ietf-lsr-pce-discovery-security-support-07.txt


The IETF datatracker page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-lsr-pce-discovery-security-support/

Diff from previous version:
https://www.ietf.org/rfcdiff?url2=draft-ietf-lsr-pce-discovery-security-support-07

IETF Secretariat.


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

Re: [Lsr] Secdir last call review of draft-ietf-lsr-pce-discovery-security-support-05

[Yaron Sheffer]

Looks good to me. Thank you!

Yaron

On 8/17/21, 03:17, "Qin Wu"  wrote:

Sorry for late followup, here is the update, the diff is

https://www.ietf.org/rfcdiff?url2=draft-ietf-lsr-pce-discovery-security-support-06
Yaron, let authors know if your comments are addressed in v-06.
Thanks!

-Qin
-邮件原件-
发件人: Acee Lindem (acee) [mailto:a...@cisco.com] 
发送时间: 2021年8月17日 4:33
收件人: Qin Wu ; tom petch ; Yaron 
Sheffer ; sec...@ietf.org
抄送: draft-ietf-lsr-pce-discovery-security-support@ietf.org
主题: Re: Secdir last call review of 
draft-ietf-lsr-pce-discovery-security-support-05

Hi Qin, 

Can you publish a revision so that Yaron assure it satisfies his comments? 

Thanks,
Acee

On 8/12/21, 9:21 PM, "Qin Wu"  wrote:

Thanks Acee and Tom for good suggestion, we will take them into account.

-Qin
-邮件原件-
发件人: Acee Lindem (acee) [mailto:a...@cisco.com] 
发送时间: 2021年8月12日 1:18
收件人: tom petch ; Yaron Sheffer 
; Qin Wu ; sec...@ietf.org
抄送: draft-ietf-lsr-pce-discovery-security-support@ietf.org
主题: Re: Secdir last call review of 
draft-ietf-lsr-pce-discovery-security-support-05

I'd also recommend changing, "key names" to "key-ids or key-chain 
names" since this is what is actually being advertised.
Thanks,
Acee

On 8/10/21, 11:53 AM, "tom petch"  wrote:

From: Lsr  on behalf of Yaron Sheffer 

Sent: 10 August 2021 14:57

So let me suggest:


An offlist suggestion for you to consider

OLD
Thus before advertisement of the PCE security parameters, it 
MUST be insured that the IGP protects the authentication and integrity of the 
PCED TLV using the mechanisms defined in
[RFC5310] and [RFC5709], if the mechanism described in this 
document is used.

Moreover, as stated in [RFC5088] and [RFC5089], the IGP do not 
provide any encryption mechanisms to protect the secrecy of the PCED TLV, and 
the operator must ensure that no private data is carried in the TLV, for 
example that key names do not reveal sensitive information about the network.

NEW

 Thus before advertising the PCE security parameters, using the 
mechanism described in this document, the IGP MUST be known to provide 
authentication and integrity for the PCED TLV using the mechanisms defined in  
[RFC5304],  [RFC5310] or [RFC5709],

Moreover, as stated in [RFC5088] and [RFC5089], if the IGP does 
not provide any encryption mechanisms to protect the secrecy of the PCED TLV, 
then the operator must ensure that no private data is carried in the TLV, e.g. 
that key names do not reveal sensitive information about the network.

Tom Petch


Thanks,
Yaron

On 8/10/21, 15:01, "Qin Wu"  wrote:

Yaron:
Thank for clarification. I agree to keep the last sentence in 
the second paragraph of section 7 as is.
But I prefer to add the addition references in the previous 
sentence as follows:
"
Thus before advertisement of the PCE security parameters, it 
MUST be insured that the IGP is
protected for authentication and integrity of the PCED TLV,, 
with the mechanisms defined in
[RFC5310] and [RFC5709] if the mechanism described in this 
document is used.

As stated in [RFC5088] and [RFC5089], the IGP do not provide 
encryption mechanism to protect
the privacy of the PCED TLV, if this information can make the 
PCEP session less secure then the operator should take that into consideration.
"
If you better wording, please let me know.

-Qin
-邮件原件-
发件人: Yaron Sheffer [mailto:yaronf.i...@gmail.com]
发送时间: 2021年8月10日 19:26
收件人: Qin Wu ; sec...@ietf.org
抄送: draft-ietf-lsr-pce-discovery-security-support@ietf.org; 
last-c...@ietf.org; lsr@ietf.org
主题: Re: Secdir last call review of 
draft-ietf-lsr-pce-discovery-security-support-05

Hi Qin,

Sorry, but I find your latest proposed text very confusing, 
because we should be focusing on integrity protection and not privacy 
(=secrecy) of the TLV. So I would prefer to keep the text as-is, with the 
addition of a reference to the IS-IS and OSPF security mechanisms that were 
discussed on this thread.

Thanks,
Yaron

On 8/10/21, 05:00, "Qin Wu"  wrote:

Hi, Yaron
-邮件原件-
>发件人: Yaron Sheffer [mailto:yaronf.i...@gmail.com]
>发送时间: 2021年8月9日 21:44
>收件人: Qin Wu ;