Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01

[Les Ginsberg (ginsberg)]

Zhenqiang -

In regards to:


[Zhenqiang]Since paths for IP flex-algo are calculated within specific MT, I 
think one new top-level TLV for ISIS is enough to advertise prefix reachability 
associated with a Flex-Algorithm, that is the one defined in section 6.1. MTID 
can be used to indicate it is for IPv4 or IPv6.


You have misunderstood RFC 5120.
It is true that the reserved MTIDs defined in 
https://www.rfc-editor.org/rfc/rfc5120.html Section 7.5  are restricted to 
support only a single AFI/SAFI, but non-reserved MTIDs are NOT subject to this 
restriction. It is quite possible to use one of the unreserved MTIDs and 
support forwarding of both IPv4 and IPv6 address families on the topology 
associated with that MTID. Therefore, it is necessary to define AF specific 
TLVs. And that is why RFC 5120 did so and why this draft also must do so.

Draft authors -

https://tools.ietf.org/html/draft-bonica-lsr-ip-flexalgo-01#section-6.2 states:

"The ISIS IPv6 Algorithm Prefix Reachability TLV is identical to the
   ISIS IPv4 Algorithm Prefix Reachability TLV, except that it has a
   unique type."

But this is not completely accurate.
The existing Prefix Reachability TLVs for IPV4 (135, 235) and IPv6 (236, 237) 
have different flags formats.
See https://www.rfc-editor.org/rfc/rfc5305.html#section-4 and 
https://www.rfc-editor.org/rfc/rfc5308.html  Section 2 respectively.
And of course the legal ranges for prefix length are different.

I would expect these differences to be preserved in the new TLVs defined in 
this draft. It would therefore be better (and more accurate) if you replaced 
the above statement with a diagram for the new IPv6 TLV comparable to the one 
in Section 6.1.

Thanx.

   Les


From: Lsr  On Behalf Of li_zhenqi...@hotmail.com
Sent: Wednesday, December 09, 2020 8:04 PM
To: Peter Psenak ; Dongjie (Jimmy) 
; Acee Lindem (acee) ; 
lsr 
Subject: Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms 
(Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01

Hello Peter,

follow-up questions with [Zhenqiang].

FA calculation is done for every MT topology independently.
For IPv4 it will take all routers participating in MT0 and run the FA
calculation on top of MT0.
For IPv6 it will take all routers participating in MT2 and run the FA
calculation on top of MT2.

[Zhenqiang] Could you please elaborate this explicitly in the draft? For 
example, in section 7, replace the setence "IP Flex-Algorithm application only 
considers participating nodes during the Flex-Algorithm calculation" with "IP 
Flex-Algorithm application only considers participating nodes within the same 
MTID during the Flex-Algorithm calculation".

[Zhenqiang]Since paths for IP flex-algo are calculated within specific MT, I 
think one new top-level TLV for ISIS is enough to advertise prefix reachability 
associated with a Flex-Algorithm, that is the one defined in section 6.1. MTID 
can be used to indicate it is for IPv4 or IPv6.

Best Regards,
Zhenqiang Li

li_zhenqi...@hotmail.com

From: Peter Psenak
Date: 2020-12-09 21:05
To: Dongjie (Jimmy); Acee Lindem 
(acee); lsr
Subject: Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms 
(Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01
Hi Jimmy,

On 09/12/2020 13:52, Dongjie (Jimmy) wrote:
> Hi Peter,
>
>> -Original Message-
>> From: Peter Psenak [mailto:ppse...@cisco.com]
>> Sent: Wednesday, December 9, 2020 6:45 PM
>> To: Dongjie (Jimmy) mailto:jie.d...@huawei.com>>; Acee 
>> Lindem (acee)
>> mailto:acee=40cisco@dmarc.ietf.org>>; 
>> lsr mailto:lsr@ietf.org>>
>> Subject: Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms
>> (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01
>>
>> Jimmy,
>>
>> On 09/12/2020 11:10, Dongjie (Jimmy) wrote:
>>> Hi authors,
>>>
>>> Here is one comment following the previous discussion on the mail list
>>> and the IETF meeting.
>>>
>>> The IP Algorithm TLV is defined to advertise the IP Flex-Algorithm
>>> participation information, there is no separate TLV for IPv4 or IPv6
>>> Flex-Algo participation.
>>
>> the draft clearly says:
>>
>>  "The IP Flex-Algorithm participation advertised in ISIS IP Algorithm
>>  Sub-TLV is topology independent."
>
> This does not answer my question.
>
> Section 7 gives the rules of IP Flex-Algo Path calculation:
>
> " IP Flex-Algorithm application only considers participating nodes during the 
> Flex-Algorithm calculation.  When computing paths for a given Flex-Algorithm, 
> all nodes that do not advertise participation for IP Flex-Algorithm, as 
> described in Section 5, MUST be pruned from the topology."
>
>>From IP Algorithm TLV, one cannot tell whether a node participates in 
>>Flex-Algo 128 for IPv4, IPv6 or both. This would cause the problem described 
>>below: 

Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01

[li_zhenqi...@hotmail.com]

Hello Peter,

follow-up questions with [Zhenqiang].

FA calculation is done for every MT topology independently. 
For IPv4 it will take all routers participating in MT0 and run the FA
calculation on top of MT0. 
For IPv6 it will take all routers participating in MT2 and run the FA
calculation on top of MT2.

[Zhenqiang] Could you please elaborate this explicitly in the draft? For 
example, in section 7, replace the setence "IP Flex-Algorithm application only 
considers participating nodes during the Flex-Algorithm calculation" with "IP 
Flex-Algorithm application only considers participating nodes within the same 
MTID during the Flex-Algorithm calculation".

[Zhenqiang]Since paths for IP flex-algo are calculated within specific MT, I 
think one new top-level TLV for ISIS is enough to advertise prefix reachability 
associated with a Flex-Algorithm, that is the one defined in section 6.1. MTID 
can be used to indicate it is for IPv4 or IPv6.

Best Regards,
Zhenqiang Li


li_zhenqi...@hotmail.com
 
From: Peter Psenak
Date: 2020-12-09 21:05
To: Dongjie (Jimmy); Acee Lindem (acee); lsr
Subject: Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms 
(Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01
Hi Jimmy,
 
On 09/12/2020 13:52, Dongjie (Jimmy) wrote:
> Hi Peter,
> 
>> -Original Message-
>> From: Peter Psenak [mailto:ppse...@cisco.com]
>> Sent: Wednesday, December 9, 2020 6:45 PM
>> To: Dongjie (Jimmy) ; Acee Lindem (acee)
>> ; lsr 
>> Subject: Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms
>> (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01
>>
>> Jimmy,
>>
>> On 09/12/2020 11:10, Dongjie (Jimmy) wrote:
>>> Hi authors,
>>>
>>> Here is one comment following the previous discussion on the mail list
>>> and the IETF meeting.
>>>
>>> The IP Algorithm TLV is defined to advertise the IP Flex-Algorithm
>>> participation information, there is no separate TLV for IPv4 or IPv6
>>> Flex-Algo participation.
>>
>> the draft clearly says:
>>
>>  "The IP Flex-Algorithm participation advertised in ISIS IP Algorithm
>>  Sub-TLV is topology independent."
> 
> This does not answer my question.
> 
> Section 7 gives the rules of IP Flex-Algo Path calculation:
> 
> " IP Flex-Algorithm application only considers participating nodes during the 
> Flex-Algorithm calculation.  When computing paths for a given Flex-Algorithm, 
> all nodes that do not advertise participation for IP Flex-Algorithm, as 
> described in Section 5, MUST be pruned from the topology."
> 
>>From IP Algorithm TLV, one cannot tell whether a node participates in 
>>Flex-Algo 128 for IPv4, IPv6 or both. This would cause the problem described 
>>below: >
> When one node uses IP Flex-Algo participation to compute a path for an IPv6 
> address advertised with Flex-Algo 128, it will not prune the nodes which 
> participate in Flex-Algo 128 for IPv4 only from the topology. Thus IPv6 
> packets following that path may get dropped on nodes which participates in 
> Flex-Algo 128 for IPv4 only.
 
FA calculation is done for every MT topology independently.
 
For IPv4 it will take all routers participating in MT0 and run the FA 
calculation on top of MT0.
 
For IPv6 it will take all routers participating in MT2 and run the FA 
calculation on top of MT2.
 
 
> 
>>
>>> If some nodes participate in IPv4 Flex-Algo 128, and some of these
>>> nodes participate in IPv6 Flex-Algo 128, how to ensure that the path
>>> computed for IPv6 Flex-Algo will not use the nodes which only
>>> participate in IPv4 Flex-Algo 128?
>>
>> there is no such thing as "IPv4 Flex-Algo 128" or "IPv6 Flex-Algo 128".
>> There is only algo 128.
> 
> Agree that Flex-Algo 128 is application or data plane agnostic, and as we 
> discussed the same Flex-Algo can be used with both IPv4 and IPv6 (maybe also 
> for SR-MPLS, SRv6). These terms are used as shorthand of "Flex-Algo 128 used 
> with IPv4 or IPv6"
> 
>> You are mixing data plane support with algo participation.
> 
> I understand Flex-Algo definition is application agnostic, and Flex-Algo 
> participation is application specific, it is just not clear to me whether 
> IPv4 and IPv6 can be treated as one application.
 
yes they can.
 
> 
>> If you want an algo to only include nodes that supports specific data plane,
>> you would need to define a specific algo for it.
> 
> This IMO contradicts with the base concept: Flex-Algo definition is 
> application (or data plane) agnostic.
 
not really, see above.
 
thanks,
Peter
 
> 
> Best regards,
> Jie
> 
>>
>> thanks,
>> Peter
>>
>>
>>>
>>> Best regards,
>>>
>>> Jie
>>>
>>> *From:*Lsr [mailto:lsr-boun...@ietf.org] *On Behalf Of *Acee Lindem
>>> (acee)
>>> *Sent:* Wednesday, December 2, 2020 5:13 AM
>>> *To:* lsr 
>>> *Subject:* [Lsr] WG Adoption Call for "IGP Flexible Algorithms
>>> (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01
>>>
>>> This IP Flex Algorithm draft generated quite a bit of discussion on
>>> use cases and deployment pri

Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01

[peng.shaofu]

Hi Peter,






Is it possible for a TI-LFA path, expressed as a native IP address list,  to be 
encoded in a Routing Header which is not necessarily Segment Routing Header, or 
to be encoded in LSRR option defined in RFC791 ?






Regards,


PSF














原始邮件



发件人：PeterPsenak
收件人：Huzhibo;Acee Lindem (acee);lsr;
日 期 ：2020年12月09日 20:44
主 题 ：Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms (Flex-Algorithm) 
In IP Networks" - draft-bonica-lsr-ip-flexalgo-01


Hi Zhibo,
 
On 09/12/2020 13:05, Huzhibo wrote:
> Hi Peter:
>  
>  If Ti-LFA can protect IP flexalgo, the native IP and SR must share the 
> same algorithm ID.
 
that is correct.
 
thanks,
Peter
>  
> thanks,
> Zhibo
>  
> -Original Message-
> From: Peter Psenak [mailto:ppse...@cisco.com]
> Sent: Wednesday, December 9, 2020 7:16 PM
> To: Huzhibo ; Acee Lindem (acee) 
> ; lsr  
> Subject: Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms 
> (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01
>  
> Zhibo,
>  
> On 09/12/2020 11:50, Huzhibo wrote:
>> Hi authors,
>> 
>> Here are some comments about IP flexalgo as follows:
>> 
>> 1.In Flex-Algo draft, there is description about using fast-rerouting
>> with Flex-Algo for SR-MPLS and SRv6 data plane. It is recommended that
>> similar text be added for IP Flex-Algo.
>  
> there is a similar text in section 8, but more work is required indeed.
>  
> One important note - TI-LFA requires some form of traffic steering. This can 
> be achieved by enabling both IP and SR flex-algo and use SR FA only to 
> protect IP FA, similar to protection of "unlabeled" traffic with SR MPLS. Or 
> some alternative mechanism for enforcing the traffic on the LFA path is 
> required.
>  
>> 
>> 2.Is Application-Specific Link Attribute (ASLA) MUST be used for IP
>> Flex-Algo path computation?
>  
> yes, the flex-algo application uses Flex-algo specific link attributes as 
> defined in base flex-algo draft.
>  
> thanks,
> Peter
>> 
>> Best regards,
>> 
>> Zhibo
>> 
>> *From:*Lsr [mailto:lsr-boun...@ietf.org] *On Behalf Of *Acee Lindem
>> (acee)
>> *Sent:* Wednesday, December 2, 2020 5:13 AM
>> *To:* lsr  
>> *Subject:* [Lsr] WG Adoption Call for "IGP Flexible Algorithms
>> (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01
>> 
>> This IP Flex Algorithm draft generated quite a bit of discussion on
>> use cases and deployment prior to IETF 109 and there was generally
>> support for WG adoption. This begins a two week WG adoption call.
>> Please indicate your support or objection to WG adoption on this list
>> prior to
>> 12:00 AM UTC on December 16^th , 2020. Also, review comments are
>> certainly welcome.
>> 
>> Thanks,
>> 
>> Acee
>> 
>  
>  
>  
 
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Working Group Last Call for "YANG Module for IS-IS Reverse Metric" - draft-ietf-lsr-yang-isis-reverse-metric-01

[Acee Lindem (acee)]

Speaking as WG member:

Hi Chris, Tom, 

On 12/9/20, 6:03 AM, "Lsr on behalf of tom petch"  wrote:

From: Lsr  on behalf of Acee Lindem (acee) 

Sent: 30 November 2020 18:14


Two thoughts
isis-rmetric is a bit long as a prefix - I note that the examples use rm 
which is a bit short.  Perhaps isis-rm

I agree. 

te-metric contains the value if the sub-tlv is present.  What if it is not 
present?

I don’t see this described in RFC 8500 (while it is in the OSPF Reverse Metric 
draft). This needs to be resolved. 

  Is there any way to tell if it is present  or not?

Just get the config using NETCONF.

Thanks,
Acee


Tom Petch

As stated as the IETF 109 LSR WG meeting, we feel the IS-IS reverse metric 
augmentation is ready for publication. This begins a two week last call for the 
subject draft. Please indicate your support or objection on this list prior to 
12:00 AM UTC on December 15th, 2020. Also, review comments are certainly 
welcome.
Thanks,
Acee


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

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

Re: [Lsr] RFC4750: OSPF Version 2 Management Information Base

[Muthu Arul Mozhi Perumal]

Thanks, Acee. I thought about the ospfIfConfigError trap with the noError
code. Would have been nice if noError was defined as 255 with 13 to 254
defined for future definitions, but that ship already sailed far and out :)

Regards,
Muthu

On Wed, Dec 9, 2020 at 8:52 PM Acee Lindem (acee)  wrote:

> Hi Muthu,
>
> In that case, I would just send ospfIfRxBadPacket – it contains the local
> and remote IP addresses in the trap data. Or, you could use ospfIfConfigError
> and you could set the error to noError since there isn’t one explicitly
> defined for this situation.
>
> Good Luck,
>
> Acee
>
>
>
>
>
>
>
> *From: *Muthu Arul Mozhi Perumal 
> *Date: *Wednesday, December 9, 2020 at 8:51 AM
> *To: *Acee Lindem 
> *Cc: *"Acee Lindem (acee)" , "
> lsr@ietf.org" , Tulasi Rami Reddy N 
> *Subject: *Re: [Lsr] RFC4750: OSPF Version 2 Management Information Base
>
>
>
> Hi Acee,
>
>
>
> We aren't generating any trap today for the subnet mismatch case. We
> wanted to get some feedback on what would be an appropriate trap to
> generate from a usability standpoint, if we want to generate one..
>
>
>
> Regards,
>
> Muthu
>
>
>
> On Wed, Dec 9, 2020 at 7:09 PM Acee Lindem (acee)  wrote:
>
> Hi Muthu,
>
> There isn’t a specific case for this specific error so I wouldn’t reuse
> the any of the specific ones with the trap. Like I said, some
> implementations don’t generate any OSPF MIB trap for this case. What are
> you doing today?
>
> Thanks,
>
> Acee
>
>
>
> *From: *Lsr  on behalf of Muthu Arul Mozhi Perumal <
> muthu.a...@gmail.com>
> *Date: *Wednesday, December 9, 2020 at 8:18 AM
> *To: *"Acee Lindem (acee)" 
> *Cc: *"lsr@ietf.org" , Tulasi Rami Reddy N <
> tulasi.i...@gmail.com>
> *Subject: *Re: [Lsr] RFC4750: OSPF Version 2 Management Information Base
>
>
>
> Hi Acee,
>
>
>
> This is a configuration error, right? Wouldn't ospfIfConfigError trap be
> more appropriate? There is no good error code for this case
> in ospfConfigErrorType, though. Perhaps, RFC4750 could have reserved some
> error codes for future definitions?
>
>
>
> Regards,
>
> Muthu
>
>
>
> On Wed, Dec 9, 2020 at 6:16 PM Acee Lindem (acee)  40cisco@dmarc.ietf.org> wrote:
>
> Hi Tulasi,
>
> You definitely shouldn’t generate the netMaskMismatch trap as this is for
> mask mismatch detection on hello packets. You could generate the
> ospfIfRxBadPacket but many do not for this case.
>
> Thanks,
>
> Acee
>
>
>
> *From: *Lsr  on behalf of Tulasi Rami Reddy N <
> tulasi.i...@gmail.com>
> *Date: *Wednesday, December 9, 2020 at 6:11 AM
> *To: *"lsr@ietf.org" 
> *Subject: *Re: [Lsr] RFC4750: OSPF Version 2 Management Information Base
>
>
>
> [ Sorry, My previous mail was truncated]
>
> Hi ,
>
>
>
> OSPFv2 adjacency will be formed on a numbered LAN only below both
> conditions are met:
>
>1. Common IP subnet
>
>2. Matching network mask.
>
> From the OSPFv2 MIB, there is only one error defined.
>
>
>
>  ospfConfigErrorType OBJECT-TYPE
>   SYNTAX   INTEGER {
>
>   *netMaskMismatch (7),*
>}
>
>
>
> I believe this is for the case 2 (when mask is mismatched).
>
>
>
> Let's take below example:
>
>
>
>   RTA(11.1.1.2/24)    (10.1.1.1/24) RTB
>
>
>
> Here, src IP is not matching to the Rx interface IP subnet, then what is
> the error type to be set?
>
> Should this be considered as generic input processing error and
> only generate
>
> *ospfIfRxBadPacket *notification or *netMaskMismatch  *notification?
>
> Should we need a new type here?
>
>
>
> "
>
> The generic input processing of OSPF packets will
>
> have checked the validity of the IP header and the OSPF packet
>
> header."
>
>
>
>
>
>
>
> Thanks,
>
> Tulasi.
>
> On Wed, Dec 9, 2020 at 4:27 PM Tulasi Rami Reddy N 
> wrote:
>
> Hi ,
>
>
>
> OSPFv2 adjacency will be formed on a numbered LAN only when
>
>1. Common IP subnet
>
> 2.matching network mask.
>
> From the
>
>
>
> Thanks,
>
> TUlasi.
>
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] RFC4750: OSPF Version 2 Management Information Base

[Acee Lindem (acee)]

Hi Muthu,
In that case, I would just send ospfIfRxBadPacket – it contains the local and 
remote IP addresses in the trap data. Or, you could use ospfIfConfigError and 
you could set the error to noError since there isn’t one explicitly defined for 
this situation.
Good Luck,
Acee



From: Muthu Arul Mozhi Perumal 
Date: Wednesday, December 9, 2020 at 8:51 AM
To: Acee Lindem 
Cc: "Acee Lindem (acee)" , "lsr@ietf.org" 
, Tulasi Rami Reddy N 
Subject: Re: [Lsr] RFC4750: OSPF Version 2 Management Information Base

Hi Acee,

We aren't generating any trap today for the subnet mismatch case. We wanted to 
get some feedback on what would be an appropriate trap to generate from a 
usability standpoint, if we want to generate one..

Regards,
Muthu

On Wed, Dec 9, 2020 at 7:09 PM Acee Lindem (acee) 
mailto:a...@cisco.com>> wrote:
Hi Muthu,
There isn’t a specific case for this specific error so I wouldn’t reuse the any 
of the specific ones with the trap. Like I said, some implementations don’t 
generate any OSPF MIB trap for this case. What are you doing today?
Thanks,
Acee

From: Lsr mailto:lsr-boun...@ietf.org>> on behalf of 
Muthu Arul Mozhi Perumal mailto:muthu.a...@gmail.com>>
Date: Wednesday, December 9, 2020 at 8:18 AM
To: "Acee Lindem (acee)" 
mailto:40cisco@dmarc.ietf.org>>
Cc: "lsr@ietf.org" mailto:lsr@ietf.org>>, 
Tulasi Rami Reddy N mailto:tulasi.i...@gmail.com>>
Subject: Re: [Lsr] RFC4750: OSPF Version 2 Management Information Base

Hi Acee,

This is a configuration error, right? Wouldn't ospfIfConfigError trap be more 
appropriate? There is no good error code for this case in ospfConfigErrorType, 
though. Perhaps, RFC4750 could have reserved some error codes for future 
definitions?

Regards,
Muthu

On Wed, Dec 9, 2020 at 6:16 PM Acee Lindem (acee) 
mailto:40cisco@dmarc.ietf.org>> wrote:
Hi Tulasi,
You definitely shouldn’t generate the netMaskMismatch trap as this is for mask 
mismatch detection on hello packets. You could generate the ospfIfRxBadPacket 
but many do not for this case.
Thanks,
Acee

From: Lsr mailto:lsr-boun...@ietf.org>> on behalf of 
Tulasi Rami Reddy N mailto:tulasi.i...@gmail.com>>
Date: Wednesday, December 9, 2020 at 6:11 AM
To: "lsr@ietf.org" mailto:lsr@ietf.org>>
Subject: Re: [Lsr] RFC4750: OSPF Version 2 Management Information Base

[ Sorry, My previous mail was truncated]
Hi ,

OSPFv2 adjacency will be formed on a numbered LAN only below both conditions 
are met:
   1. Common IP subnet
   2. Matching network mask.
From the OSPFv2 MIB, there is only one error defined.

 ospfConfigErrorType OBJECT-TYPE
  SYNTAX   INTEGER {

  netMaskMismatch (7),
   }

I believe this is for the case 2 (when mask is mismatched).

Let's take below example:

  RTA(11.1.1.2/24)    
(10.1.1.1/24) RTB

Here, src IP is not matching to the Rx interface IP subnet, then what is the 
error type to be set?
Should this be considered as generic input processing error and only generate
ospfIfRxBadPacket notification or netMaskMismatch  notification?
Should we need a new type here?

"
The generic input processing of OSPF packets will
have checked the validity of the IP header and the OSPF packet
header."



Thanks,
Tulasi.
On Wed, Dec 9, 2020 at 4:27 PM Tulasi Rami Reddy N 
mailto:tulasi.i...@gmail.com>> wrote:
Hi ,

OSPFv2 adjacency will be formed on a numbered LAN only when
   1. Common IP subnet
2.matching network mask.
From the

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

Re: [Lsr] RFC4750: OSPF Version 2 Management Information Base

[Muthu Arul Mozhi Perumal]

Hi Acee,

We aren't generating any trap today for the subnet mismatch case. We wanted
to get some feedback on what would be an appropriate trap to generate from
a usability standpoint, if we want to generate one..

Regards,
Muthu

On Wed, Dec 9, 2020 at 7:09 PM Acee Lindem (acee)  wrote:

> Hi Muthu,
>
> There isn’t a specific case for this specific error so I wouldn’t reuse
> the any of the specific ones with the trap. Like I said, some
> implementations don’t generate any OSPF MIB trap for this case. What are
> you doing today?
>
> Thanks,
>
> Acee
>
>
>
> *From: *Lsr  on behalf of Muthu Arul Mozhi Perumal <
> muthu.a...@gmail.com>
> *Date: *Wednesday, December 9, 2020 at 8:18 AM
> *To: *"Acee Lindem (acee)" 
> *Cc: *"lsr@ietf.org" , Tulasi Rami Reddy N <
> tulasi.i...@gmail.com>
> *Subject: *Re: [Lsr] RFC4750: OSPF Version 2 Management Information Base
>
>
>
> Hi Acee,
>
>
>
> This is a configuration error, right? Wouldn't ospfIfConfigError trap be
> more appropriate? There is no good error code for this case
> in ospfConfigErrorType, though. Perhaps, RFC4750 could have reserved some
> error codes for future definitions?
>
>
>
> Regards,
>
> Muthu
>
>
>
> On Wed, Dec 9, 2020 at 6:16 PM Acee Lindem (acee)  40cisco@dmarc.ietf.org> wrote:
>
> Hi Tulasi,
>
> You definitely shouldn’t generate the netMaskMismatch trap as this is for
> mask mismatch detection on hello packets. You could generate the
> ospfIfRxBadPacket but many do not for this case.
>
> Thanks,
>
> Acee
>
>
>
> *From: *Lsr  on behalf of Tulasi Rami Reddy N <
> tulasi.i...@gmail.com>
> *Date: *Wednesday, December 9, 2020 at 6:11 AM
> *To: *"lsr@ietf.org" 
> *Subject: *Re: [Lsr] RFC4750: OSPF Version 2 Management Information Base
>
>
>
> [ Sorry, My previous mail was truncated]
>
> Hi ,
>
>
>
> OSPFv2 adjacency will be formed on a numbered LAN only below both
> conditions are met:
>
>1. Common IP subnet
>
>2. Matching network mask.
>
> From the OSPFv2 MIB, there is only one error defined.
>
>
>
>  ospfConfigErrorType OBJECT-TYPE
>   SYNTAX   INTEGER {
>
>   *netMaskMismatch (7),*
>}
>
>
>
> I believe this is for the case 2 (when mask is mismatched).
>
>
>
> Let's take below example:
>
>
>
>   RTA(11.1.1.2/24)    (10.1.1.1/24) RTB
>
>
>
> Here, src IP is not matching to the Rx interface IP subnet, then what is
> the error type to be set?
>
> Should this be considered as generic input processing error and
> only generate
>
> *ospfIfRxBadPacket *notification or *netMaskMismatch  *notification?
>
> Should we need a new type here?
>
>
>
> "
>
> The generic input processing of OSPF packets will
>
> have checked the validity of the IP header and the OSPF packet
>
> header."
>
>
>
>
>
>
>
> Thanks,
>
> Tulasi.
>
> On Wed, Dec 9, 2020 at 4:27 PM Tulasi Rami Reddy N 
> wrote:
>
> Hi ,
>
>
>
> OSPFv2 adjacency will be formed on a numbered LAN only when
>
>1. Common IP subnet
>
> 2.matching network mask.
>
> From the
>
>
>
> Thanks,
>
> TUlasi.
>
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] RFC4750: OSPF Version 2 Management Information Base

[Acee Lindem (acee)]

Hi Muthu,
There isn’t a specific case for this specific error so I wouldn’t reuse the any 
of the specific ones with the trap. Like I said, some implementations don’t 
generate any OSPF MIB trap for this case. What are you doing today?
Thanks,
Acee

From: Lsr  on behalf of Muthu Arul Mozhi Perumal 

Date: Wednesday, December 9, 2020 at 8:18 AM
To: "Acee Lindem (acee)" 
Cc: "lsr@ietf.org" , Tulasi Rami Reddy N 
Subject: Re: [Lsr] RFC4750: OSPF Version 2 Management Information Base

Hi Acee,

This is a configuration error, right? Wouldn't ospfIfConfigError trap be more 
appropriate? There is no good error code for this case in ospfConfigErrorType, 
though. Perhaps, RFC4750 could have reserved some error codes for future 
definitions?

Regards,
Muthu

On Wed, Dec 9, 2020 at 6:16 PM Acee Lindem (acee) 
mailto:40cisco@dmarc.ietf.org>> wrote:
Hi Tulasi,
You definitely shouldn’t generate the netMaskMismatch trap as this is for mask 
mismatch detection on hello packets. You could generate the ospfIfRxBadPacket 
but many do not for this case.
Thanks,
Acee

From: Lsr mailto:lsr-boun...@ietf.org>> on behalf of 
Tulasi Rami Reddy N mailto:tulasi.i...@gmail.com>>
Date: Wednesday, December 9, 2020 at 6:11 AM
To: "lsr@ietf.org" mailto:lsr@ietf.org>>
Subject: Re: [Lsr] RFC4750: OSPF Version 2 Management Information Base

[ Sorry, My previous mail was truncated]
Hi ,

OSPFv2 adjacency will be formed on a numbered LAN only below both conditions 
are met:
   1. Common IP subnet
   2. Matching network mask.
From the OSPFv2 MIB, there is only one error defined.

 ospfConfigErrorType OBJECT-TYPE
  SYNTAX   INTEGER {

  netMaskMismatch (7),
   }

I believe this is for the case 2 (when mask is mismatched).

Let's take below example:

  RTA(11.1.1.2/24)    
(10.1.1.1/24) RTB

Here, src IP is not matching to the Rx interface IP subnet, then what is the 
error type to be set?
Should this be considered as generic input processing error and only generate
ospfIfRxBadPacket notification or netMaskMismatch  notification?
Should we need a new type here?

"
The generic input processing of OSPF packets will
have checked the validity of the IP header and the OSPF packet
header."



Thanks,
Tulasi.
On Wed, Dec 9, 2020 at 4:27 PM Tulasi Rami Reddy N 
mailto:tulasi.i...@gmail.com>> wrote:
Hi ,

OSPFv2 adjacency will be formed on a numbered LAN only when
   1. Common IP subnet
2.matching network mask.
From the

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

Re: [Lsr] RFC4750: OSPF Version 2 Management Information Base

[Muthu Arul Mozhi Perumal]

Hi Acee,

This is a configuration error, right? Wouldn't ospfIfConfigError trap be
more appropriate? There is no good error code for this case in
ospfConfigErrorType,
though. Perhaps, RFC4750 could have reserved some error codes for future
definitions?

Regards,
Muthu

On Wed, Dec 9, 2020 at 6:16 PM Acee Lindem (acee)  wrote:

> Hi Tulasi,
>
> You definitely shouldn’t generate the netMaskMismatch trap as this is for
> mask mismatch detection on hello packets. You could generate the
> ospfIfRxBadPacket but many do not for this case.
>
> Thanks,
>
> Acee
>
>
>
> *From: *Lsr  on behalf of Tulasi Rami Reddy N <
> tulasi.i...@gmail.com>
> *Date: *Wednesday, December 9, 2020 at 6:11 AM
> *To: *"lsr@ietf.org" 
> *Subject: *Re: [Lsr] RFC4750: OSPF Version 2 Management Information Base
>
>
>
> [ Sorry, My previous mail was truncated]
>
> Hi ,
>
>
>
> OSPFv2 adjacency will be formed on a numbered LAN only below both
> conditions are met:
>
>1. Common IP subnet
>
>2. Matching network mask.
>
> From the OSPFv2 MIB, there is only one error defined.
>
>
>
>  ospfConfigErrorType OBJECT-TYPE
>   SYNTAX   INTEGER {
>
>   *netMaskMismatch (7),*
>}
>
>
>
> I believe this is for the case 2 (when mask is mismatched).
>
>
>
> Let's take below example:
>
>
>
>   RTA(11.1.1.2/24)    (10.1.1.1/24) RTB
>
>
>
> Here, src IP is not matching to the Rx interface IP subnet, then what is
> the error type to be set?
>
> Should this be considered as generic input processing error and
> only generate
>
> *ospfIfRxBadPacket *notification or *netMaskMismatch  *notification?
>
> Should we need a new type here?
>
>
>
> "
>
> The generic input processing of OSPF packets will
>
> have checked the validity of the IP header and the OSPF packet
>
> header."
>
>
>
>
>
>
>
> Thanks,
>
> Tulasi.
>
> On Wed, Dec 9, 2020 at 4:27 PM Tulasi Rami Reddy N 
> wrote:
>
> Hi ,
>
>
>
> OSPFv2 adjacency will be formed on a numbered LAN only when
>
>1. Common IP subnet
>
> 2.matching network mask.
>
> From the
>
>
>
> Thanks,
>
> TUlasi.
>
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01

[Peter Psenak]

Hi Jimmy,

On 09/12/2020 13:52, Dongjie (Jimmy) wrote:

Hi Peter,


-Original Message-
From: Peter Psenak [mailto:ppse...@cisco.com]
Sent: Wednesday, December 9, 2020 6:45 PM
To: Dongjie (Jimmy) ; Acee Lindem (acee)
; lsr 
Subject: Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms
(Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01

Jimmy,

On 09/12/2020 11:10, Dongjie (Jimmy) wrote:

Hi authors,

Here is one comment following the previous discussion on the mail list
and the IETF meeting.

The IP Algorithm TLV is defined to advertise the IP Flex-Algorithm
participation information, there is no separate TLV for IPv4 or IPv6
Flex-Algo participation.


the draft clearly says:

 "The IP Flex-Algorithm participation advertised in ISIS IP Algorithm
 Sub-TLV is topology independent."


This does not answer my question.

Section 7 gives the rules of IP Flex-Algo Path calculation:

" IP Flex-Algorithm application only considers participating nodes during the 
Flex-Algorithm calculation.  When computing paths for a given Flex-Algorithm, all nodes 
that do not advertise participation for IP Flex-Algorithm, as described in Section 5, 
MUST be pruned from the topology."


From IP Algorithm TLV, one cannot tell whether a node participates in Flex-Algo 
128 for IPv4, IPv6 or both. This would cause the problem described below: >

When one node uses IP Flex-Algo participation to compute a path for an IPv6 
address advertised with Flex-Algo 128, it will not prune the nodes which 
participate in Flex-Algo 128 for IPv4 only from the topology. Thus IPv6 packets 
following that path may get dropped on nodes which participates in Flex-Algo 
128 for IPv4 only.


FA calculation is done for every MT topology independently.

For IPv4 it will take all routers participating in MT0 and run the FA 
calculation on top of MT0.


For IPv6 it will take all routers participating in MT2 and run the FA 
calculation on top of MT2.








If some nodes participate in IPv4 Flex-Algo 128, and some of these
nodes participate in IPv6 Flex-Algo 128, how to ensure that the path
computed for IPv6 Flex-Algo will not use the nodes which only
participate in IPv4 Flex-Algo 128?


there is no such thing as "IPv4 Flex-Algo 128" or "IPv6 Flex-Algo 128".
There is only algo 128.


Agree that Flex-Algo 128 is application or data plane agnostic, and as we discussed the 
same Flex-Algo can be used with both IPv4 and IPv6 (maybe also for SR-MPLS, SRv6). These 
terms are used as shorthand of "Flex-Algo 128 used with IPv4 or IPv6"


You are mixing data plane support with algo participation.


I understand Flex-Algo definition is application agnostic, and Flex-Algo 
participation is application specific, it is just not clear to me whether IPv4 
and IPv6 can be treated as one application.


yes they can.




If you want an algo to only include nodes that supports specific data plane,
you would need to define a specific algo for it.


This IMO contradicts with the base concept: Flex-Algo definition is application 
(or data plane) agnostic.


not really, see above.

thanks,
Peter



Best regards,
Jie



thanks,
Peter




Best regards,

Jie

*From:*Lsr [mailto:lsr-boun...@ietf.org] *On Behalf Of *Acee Lindem
(acee)
*Sent:* Wednesday, December 2, 2020 5:13 AM
*To:* lsr 
*Subject:* [Lsr] WG Adoption Call for "IGP Flexible Algorithms
(Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01

This IP Flex Algorithm draft generated quite a bit of discussion on
use cases and deployment prior to IETF 109 and there was generally
support for WG adoption. This begins a two week WG adoption call.
Please indicate your support or objection to WG adoption on this list
prior to
12:00 AM UTC on December 16^th , 2020. Also, review comments are
certainly welcome.

Thanks,

Acee







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

Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01

[Dongjie (Jimmy)]

Hi Parag,

Thanks for your reply. While perhaps I should make my comment clearer:

I agree a node which does not support a particular address family (e.g. IPv6) 
will not install route for that family. While according to the rules in section 
7, this node will be included in the topology for path computation of one 
Flex-Algo by another node, just because it advertises the participation to the 
same Flex-Algo for another address family (e.g. IPv4). In my understanding this 
would cause packet drop. Did I miss something?

Best regards,
Jie

From: Parag Kaneriya [mailto:pkane...@juniper.net]
Sent: Wednesday, December 9, 2020 6:46 PM
To: Dongjie (Jimmy) ; Acee Lindem (acee) 
; lsr 
Subject: RE: WG Adoption Call for "IGP Flexible Algorithms (Flex-Algorithm) In 
IP Networks" - draft-bonica-lsr-ip-flexalgo-01

IP Algorithm SUBTLV indicate the participation for particular flex algo by 
node.  Participation doesn't depend on whether it support ipv4 prefix or ipv6 
prefix.  Node which doesn't support particular family will not install that 
family route.

Regards
Parag



Juniper Business Use Only
From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of 
Dongjie (Jimmy)
Sent: Wednesday, December 9, 2020 3:40 PM
To: Acee Lindem (acee) 
mailto:acee=40cisco@dmarc.ietf.org>>; lsr 
mailto:lsr@ietf.org>>
Subject: Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms 
(Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01

[External Email. Be cautious of content]

Hi authors,

Here is one comment following the previous discussion on the mail list and the 
IETF meeting.

The IP Algorithm TLV is defined to advertise the IP Flex-Algorithm 
participation information, there is no separate TLV for IPv4 or IPv6 Flex-Algo 
participation. If some nodes participate in IPv4 Flex-Algo 128, and some of 
these nodes participate in IPv6 Flex-Algo 128, how to ensure that the path 
computed for IPv6 Flex-Algo will not use the nodes which only participate in 
IPv4 Flex-Algo 128?

Best regards,
Jie

From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Acee Lindem (acee)
Sent: Wednesday, December 2, 2020 5:13 AM
To: lsr mailto:lsr@ietf.org>>
Subject: [Lsr] WG Adoption Call for "IGP Flexible Algorithms (Flex-Algorithm) 
In IP Networks" - draft-bonica-lsr-ip-flexalgo-01

This IP Flex Algorithm draft generated quite a bit of discussion on use cases 
and deployment prior to IETF 109 and there was generally support for WG 
adoption. This begins a two week WG adoption call. Please indicate your support 
or objection to WG adoption on this list prior to 12:00 AM UTC on December 
16th, 2020. Also, review comments are certainly welcome.
Thanks,
Acee


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

Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01

[Dongjie (Jimmy)]

Hi Peter,

> -Original Message-
> From: Peter Psenak [mailto:ppse...@cisco.com]
> Sent: Wednesday, December 9, 2020 6:45 PM
> To: Dongjie (Jimmy) ; Acee Lindem (acee)
> ; lsr 
> Subject: Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms
> (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01
> 
> Jimmy,
> 
> On 09/12/2020 11:10, Dongjie (Jimmy) wrote:
> > Hi authors,
> >
> > Here is one comment following the previous discussion on the mail list
> > and the IETF meeting.
> >
> > The IP Algorithm TLV is defined to advertise the IP Flex-Algorithm
> > participation information, there is no separate TLV for IPv4 or IPv6
> > Flex-Algo participation.
> 
> the draft clearly says:
> 
> "The IP Flex-Algorithm participation advertised in ISIS IP Algorithm
> Sub-TLV is topology independent."

This does not answer my question. 

Section 7 gives the rules of IP Flex-Algo Path calculation: 

" IP Flex-Algorithm application only considers participating nodes during the 
Flex-Algorithm calculation.  When computing paths for a given Flex-Algorithm, 
all nodes that do not advertise participation for IP Flex-Algorithm, as 
described in Section 5, MUST be pruned from the topology. "

>From IP Algorithm TLV, one cannot tell whether a node participates in 
>Flex-Algo 128 for IPv4, IPv6 or both. This would cause the problem described 
>below: 

When one node uses IP Flex-Algo participation to compute a path for an IPv6 
address advertised with Flex-Algo 128, it will not prune the nodes which 
participate in Flex-Algo 128 for IPv4 only from the topology. Thus IPv6 packets 
following that path may get dropped on nodes which participates in Flex-Algo 
128 for IPv4 only.

> 
> > If some nodes participate in IPv4 Flex-Algo 128, and some of these
> > nodes participate in IPv6 Flex-Algo 128, how to ensure that the path
> > computed for IPv6 Flex-Algo will not use the nodes which only
> > participate in IPv4 Flex-Algo 128?
> 
> there is no such thing as "IPv4 Flex-Algo 128" or "IPv6 Flex-Algo 128".
> There is only algo 128.

Agree that Flex-Algo 128 is application or data plane agnostic, and as we 
discussed the same Flex-Algo can be used with both IPv4 and IPv6 (maybe also 
for SR-MPLS, SRv6). These terms are used as shorthand of "Flex-Algo 128 used 
with IPv4 or IPv6"

> You are mixing data plane support with algo participation.

I understand Flex-Algo definition is application agnostic, and Flex-Algo 
participation is application specific, it is just not clear to me whether IPv4 
and IPv6 can be treated as one application.

> If you want an algo to only include nodes that supports specific data plane,
> you would need to define a specific algo for it.

This IMO contradicts with the base concept: Flex-Algo definition is application 
(or data plane) agnostic. 

Best regards,
Jie

> 
> thanks,
> Peter
> 
> 
> >
> > Best regards,
> >
> > Jie
> >
> > *From:*Lsr [mailto:lsr-boun...@ietf.org] *On Behalf Of *Acee Lindem
> > (acee)
> > *Sent:* Wednesday, December 2, 2020 5:13 AM
> > *To:* lsr 
> > *Subject:* [Lsr] WG Adoption Call for "IGP Flexible Algorithms
> > (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01
> >
> > This IP Flex Algorithm draft generated quite a bit of discussion on
> > use cases and deployment prior to IETF 109 and there was generally
> > support for WG adoption. This begins a two week WG adoption call.
> > Please indicate your support or objection to WG adoption on this list
> > prior to
> > 12:00 AM UTC on December 16^th , 2020. Also, review comments are
> > certainly welcome.
> >
> > Thanks,
> >
> > Acee
> >

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

Re: [Lsr] RFC4750: OSPF Version 2 Management Information Base

[Acee Lindem (acee)]

Hi Tulasi,
You definitely shouldn’t generate the netMaskMismatch trap as this is for mask 
mismatch detection on hello packets. You could generate the ospfIfRxBadPacket 
but many do not for this case.
Thanks,
Acee

From: Lsr  on behalf of Tulasi Rami Reddy N 

Date: Wednesday, December 9, 2020 at 6:11 AM
To: "lsr@ietf.org" 
Subject: Re: [Lsr] RFC4750: OSPF Version 2 Management Information Base

[ Sorry, My previous mail was truncated]
Hi ,

OSPFv2 adjacency will be formed on a numbered LAN only below both conditions 
are met:
   1. Common IP subnet
   2. Matching network mask.
From the OSPFv2 MIB, there is only one error defined.

 ospfConfigErrorType OBJECT-TYPE
  SYNTAX   INTEGER {

  netMaskMismatch (7),
   }

I believe this is for the case 2 (when mask is mismatched).

Let's take below example:

  RTA(11.1.1.2/24)    
(10.1.1.1/24) RTB

Here, src IP is not matching to the Rx interface IP subnet, then what is the 
error type to be set?
Should this be considered as generic input processing error and only generate
ospfIfRxBadPacket notification or netMaskMismatch  notification?
Should we need a new type here?

"
The generic input processing of OSPF packets will
have checked the validity of the IP header and the OSPF packet
header."



Thanks,
Tulasi.
On Wed, Dec 9, 2020 at 4:27 PM Tulasi Rami Reddy N 
mailto:tulasi.i...@gmail.com>> wrote:
Hi ,

OSPFv2 adjacency will be formed on a numbered LAN only when
   1. Common IP subnet
2.matching network mask.
From the

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

Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01

[Peter Psenak]

Hi Zhibo,

On 09/12/2020 13:05, Huzhibo wrote:

Hi Peter:

 If Ti-LFA can protect IP flexalgo, the native IP and SR must share the 
same algorithm ID.


that is correct.

thanks,
Peter


thanks,
Zhibo

-Original Message-
From: Peter Psenak [mailto:ppse...@cisco.com]
Sent: Wednesday, December 9, 2020 7:16 PM
To: Huzhibo ; Acee Lindem (acee) 
; lsr 
Subject: Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms (Flex-Algorithm) In 
IP Networks" - draft-bonica-lsr-ip-flexalgo-01

Zhibo,

On 09/12/2020 11:50, Huzhibo wrote:

Hi authors,

Here are some comments about IP flexalgo as follows:

1.In Flex-Algo draft, there is description about using fast-rerouting
with Flex-Algo for SR-MPLS and SRv6 data plane. It is recommended that
similar text be added for IP Flex-Algo.


there is a similar text in section 8, but more work is required indeed.

One important note - TI-LFA requires some form of traffic steering. This can be achieved 
by enabling both IP and SR flex-algo and use SR FA only to protect IP FA, similar to 
protection of "unlabeled" traffic with SR MPLS. Or some alternative mechanism 
for enforcing the traffic on the LFA path is required.



2.Is Application-Specific Link Attribute (ASLA) MUST be used for IP
Flex-Algo path computation?


yes, the flex-algo application uses Flex-algo specific link attributes as 
defined in base flex-algo draft.

thanks,
Peter


Best regards,

Zhibo

*From:*Lsr [mailto:lsr-boun...@ietf.org] *On Behalf Of *Acee Lindem
(acee)
*Sent:* Wednesday, December 2, 2020 5:13 AM
*To:* lsr 
*Subject:* [Lsr] WG Adoption Call for "IGP Flexible Algorithms
(Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01

This IP Flex Algorithm draft generated quite a bit of discussion on
use cases and deployment prior to IETF 109 and there was generally
support for WG adoption. This begins a two week WG adoption call.
Please indicate your support or objection to WG adoption on this list
prior to
12:00 AM UTC on December 16^th , 2020. Also, review comments are
certainly welcome.

Thanks,

Acee







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

Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01

[Huzhibo]

Hi Peter:

If Ti-LFA can protect IP flexalgo, the native IP and SR must share the same 
algorithm ID.

thanks,
Zhibo

-Original Message-
From: Peter Psenak [mailto:ppse...@cisco.com] 
Sent: Wednesday, December 9, 2020 7:16 PM
To: Huzhibo ; Acee Lindem (acee) 
; lsr 
Subject: Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms 
(Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01

Zhibo,

On 09/12/2020 11:50, Huzhibo wrote:
> Hi authors,
> 
> Here are some comments about IP flexalgo as follows:
> 
> 1.In Flex-Algo draft, there is description about using fast-rerouting 
> with Flex-Algo for SR-MPLS and SRv6 data plane. It is recommended that 
> similar text be added for IP Flex-Algo.

there is a similar text in section 8, but more work is required indeed.

One important note - TI-LFA requires some form of traffic steering. This can be 
achieved by enabling both IP and SR flex-algo and use SR FA only to protect IP 
FA, similar to protection of "unlabeled" traffic with SR MPLS. Or some 
alternative mechanism for enforcing the traffic on the LFA path is required.

> 
> 2.Is Application-Specific Link Attribute (ASLA) MUST be used for IP 
> Flex-Algo path computation?

yes, the flex-algo application uses Flex-algo specific link attributes as 
defined in base flex-algo draft.

thanks,
Peter
> 
> Best regards,
> 
> Zhibo
> 
> *From:*Lsr [mailto:lsr-boun...@ietf.org] *On Behalf Of *Acee Lindem 
> (acee)
> *Sent:* Wednesday, December 2, 2020 5:13 AM
> *To:* lsr 
> *Subject:* [Lsr] WG Adoption Call for "IGP Flexible Algorithms
> (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01
> 
> This IP Flex Algorithm draft generated quite a bit of discussion on 
> use cases and deployment prior to IETF 109 and there was generally 
> support for WG adoption. This begins a two week WG adoption call. 
> Please indicate your support or objection to WG adoption on this list 
> prior to
> 12:00 AM UTC on December 16^th , 2020. Also, review comments are 
> certainly welcome.
> 
> Thanks,
> 
> Acee
> 

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

Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01

[Peter Psenak]

Zhibo,

On 09/12/2020 11:50, Huzhibo wrote:

Hi authors,

Here are some comments about IP flexalgo as follows:

1.In Flex-Algo draft, there is description about using fast-rerouting 
with Flex-Algo for SR-MPLS and SRv6 data plane. It is recommended that 
similar text be added for IP Flex-Algo.


there is a similar text in section 8, but more work is required indeed.

One important note - TI-LFA requires some form of traffic steering. This 
can be achieved by enabling both IP and SR flex-algo and use SR FA only 
to protect IP FA, similar to protection of "unlabeled" traffic with SR 
MPLS. Or some alternative mechanism for enforcing the traffic on the LFA 
path is required.




2.Is Application-Specific Link Attribute (ASLA) MUST be used for IP 
Flex-Algo path computation?


yes, the flex-algo application uses Flex-algo specific link attributes 
as defined in base flex-algo draft.


thanks,
Peter


Best regards,

Zhibo

*From:*Lsr [mailto:lsr-boun...@ietf.org] *On Behalf Of *Acee Lindem (acee)
*Sent:* Wednesday, December 2, 2020 5:13 AM
*To:* lsr 
*Subject:* [Lsr] WG Adoption Call for "IGP Flexible Algorithms 
(Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01


This IP Flex Algorithm draft generated quite a bit of discussion on use 
cases and deployment prior to IETF 109 and there was generally support 
for WG adoption. This begins a two week WG adoption call. Please 
indicate your support or objection to WG adoption on this list prior to 
12:00 AM UTC on December 16^th , 2020. Also, review comments are 
certainly welcome.


Thanks,

Acee



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

Re: [Lsr] RFC4750: OSPF Version 2 Management Information Base

[Tulasi Rami Reddy N]

[ Sorry, My previous mail was truncated]
Hi ,

OSPFv2 adjacency will be formed on a numbered LAN only below both
conditions are met:
   1. Common IP subnet
   2. Matching network mask.
>From the OSPFv2 MIB, there is only one error defined.

 ospfConfigErrorType OBJECT-TYPE
  SYNTAX   INTEGER {

  *netMaskMismatch (7),*
   }

I believe this is for the case 2 (when mask is mismatched).

Let's take below example:

  RTA(11.1.1.2/24)    (10.1.1.1/24) RTB

Here, src IP is not matching to the Rx interface IP subnet, then what is
the error type to be set?
Should this be considered as generic input processing error and
only generate
*ospfIfRxBadPacket * notification or *netMaskMismatch  *notification?
Should we need a new type here?

"

The generic input processing of OSPF packets will

have checked the validity of the IP header and the OSPF packet
header."





Thanks,
Tulasi.
On Wed, Dec 9, 2020 at 4:27 PM Tulasi Rami Reddy N 
wrote:

> Hi ,
>
> OSPFv2 adjacency will be formed on a numbered LAN only when
>1. Common IP subnet
> 2.matching network mask.
> From the
>
> Thanks,
> TUlasi.
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Working Group Last Call for "YANG Module for IS-IS Reverse Metric" - draft-ietf-lsr-yang-isis-reverse-metric-01

[tom petch]

From: Lsr  on behalf of Acee Lindem (acee) 

Sent: 30 November 2020 18:14


Two thoughts
isis-rmetric is a bit long as a prefix - I note that the examples use rm which 
is a bit short.  Perhaps isis-rm

te-metric contains the value if the sub-tlv is present.  What if it is not 
present?  Is there any way to tell if it is present  or not?

Tom Petch

As stated as the IETF 109 LSR WG meeting, we feel the IS-IS reverse metric 
augmentation is ready for publication. This begins a two week last call for the 
subject draft. Please indicate your support or objection on this list prior to 
12:00 AM UTC on December 15th, 2020. Also, review comments are certainly 
welcome.
Thanks,
Acee


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

[Lsr] RFC4750: OSPF Version 2 Management Information Base

[Tulasi Rami Reddy N]

Hi ,

OSPFv2 adjacency will be formed on a numbered LAN only when
   1. Common IP subnet
2.matching network mask.
>From the

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

Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01

[Huzhibo]

Hi authors,

Here are some comments about IP flexalgo as follows:

1.   In Flex-Algo draft, there is description about using fast-rerouting 
with Flex-Algo for SR-MPLS and SRv6 data plane. It is recommended that similar 
text be added for IP Flex-Algo.

2.   Is Application-Specific Link Attribute (ASLA) MUST be used for IP 
Flex-Algo path computation?

Best regards,
Zhibo

From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Acee Lindem (acee)
Sent: Wednesday, December 2, 2020 5:13 AM
To: lsr 
Subject: [Lsr] WG Adoption Call for "IGP Flexible Algorithms (Flex-Algorithm) 
In IP Networks" - draft-bonica-lsr-ip-flexalgo-01

This IP Flex Algorithm draft generated quite a bit of discussion on use cases 
and deployment prior to IETF 109 and there was generally support for WG 
adoption. This begins a two week WG adoption call. Please indicate your support 
or objection to WG adoption on this list prior to 12:00 AM UTC on December 
16th, 2020. Also, review comments are certainly welcome.
Thanks,
Acee


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

Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01

[Parag Kaneriya]

IP Algorithm SUBTLV indicate the participation for particular flex algo by 
node.  Participation doesn't depend on whether it support ipv4 prefix or ipv6 
prefix.  Node which doesn't support particular family will not install that 
family route.

Regards
Parag



Juniper Business Use Only
From: Lsr  On Behalf Of Dongjie (Jimmy)
Sent: Wednesday, December 9, 2020 3:40 PM
To: Acee Lindem (acee) ; lsr 
Subject: Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms 
(Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01

[External Email. Be cautious of content]

Hi authors,

Here is one comment following the previous discussion on the mail list and the 
IETF meeting.

The IP Algorithm TLV is defined to advertise the IP Flex-Algorithm 
participation information, there is no separate TLV for IPv4 or IPv6 Flex-Algo 
participation. If some nodes participate in IPv4 Flex-Algo 128, and some of 
these nodes participate in IPv6 Flex-Algo 128, how to ensure that the path 
computed for IPv6 Flex-Algo will not use the nodes which only participate in 
IPv4 Flex-Algo 128?

Best regards,
Jie

From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Acee Lindem (acee)
Sent: Wednesday, December 2, 2020 5:13 AM
To: lsr mailto:lsr@ietf.org>>
Subject: [Lsr] WG Adoption Call for "IGP Flexible Algorithms (Flex-Algorithm) 
In IP Networks" - draft-bonica-lsr-ip-flexalgo-01

This IP Flex Algorithm draft generated quite a bit of discussion on use cases 
and deployment prior to IETF 109 and there was generally support for WG 
adoption. This begins a two week WG adoption call. Please indicate your support 
or objection to WG adoption on this list prior to 12:00 AM UTC on December 
16th, 2020. Also, review comments are certainly welcome.
Thanks,
Acee


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

Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01

[Peter Psenak]

Jimmy,

On 09/12/2020 11:10, Dongjie (Jimmy) wrote:

Hi authors,

Here is one comment following the previous discussion on the mail list 
and the IETF meeting.


The IP Algorithm TLV is defined to advertise the IP Flex-Algorithm 
participation information, there is no separate TLV for IPv4 or IPv6 
Flex-Algo participation. 


the draft clearly says:

   "The IP Flex-Algorithm participation advertised in ISIS IP Algorithm
   Sub-TLV is topology independent."


If some nodes participate in IPv4 Flex-Algo 
128, and some of these nodes participate in IPv6 Flex-Algo 128, how to 
ensure that the path computed for IPv6 Flex-Algo will not use the nodes 
which only participate in IPv4 Flex-Algo 128?


there is no such thing as "IPv4 Flex-Algo 128" or "IPv6 Flex-Algo 128". 
There is only algo 128.


You are mixing data plane support with algo participation.

If you want an algo to only include nodes that supports specific data 
plane, you would need to define a specific algo for it.


thanks,
Peter




Best regards,

Jie

*From:*Lsr [mailto:lsr-boun...@ietf.org] *On Behalf Of *Acee Lindem (acee)
*Sent:* Wednesday, December 2, 2020 5:13 AM
*To:* lsr 
*Subject:* [Lsr] WG Adoption Call for "IGP Flexible Algorithms 
(Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01


This IP Flex Algorithm draft generated quite a bit of discussion on use 
cases and deployment prior to IETF 109 and there was generally support 
for WG adoption. This begins a two week WG adoption call. Please 
indicate your support or objection to WG adoption on this list prior to 
12:00 AM UTC on December 16^th , 2020. Also, review comments are 
certainly welcome.


Thanks,

Acee



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

Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01

[Dongjie (Jimmy)]

Hi authors,

Here is one comment following the previous discussion on the mail list and the 
IETF meeting.

The IP Algorithm TLV is defined to advertise the IP Flex-Algorithm 
participation information, there is no separate TLV for IPv4 or IPv6 Flex-Algo 
participation. If some nodes participate in IPv4 Flex-Algo 128, and some of 
these nodes participate in IPv6 Flex-Algo 128, how to ensure that the path 
computed for IPv6 Flex-Algo will not use the nodes which only participate in 
IPv4 Flex-Algo 128?

Best regards,
Jie

From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Acee Lindem (acee)
Sent: Wednesday, December 2, 2020 5:13 AM
To: lsr 
Subject: [Lsr] WG Adoption Call for "IGP Flexible Algorithms (Flex-Algorithm) 
In IP Networks" - draft-bonica-lsr-ip-flexalgo-01

This IP Flex Algorithm draft generated quite a bit of discussion on use cases 
and deployment prior to IETF 109 and there was generally support for WG 
adoption. This begins a two week WG adoption call. Please indicate your support 
or objection to WG adoption on this list prior to 12:00 AM UTC on December 
16th, 2020. Also, review comments are certainly welcome.
Thanks,
Acee


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