[Lsr] WGLC request for draft-ietf-lsr-ospf-bfd-strict-mode-04

[Ketan Talaulikar (ketant)]

Hi Acee/Chris,

On behalf of the authors, I would like to request for WGLC for this draft.

Thanks,
Ketan

-Original Message-
From: Lsr  On Behalf Of internet-dra...@ietf.org
Sent: 22 October 2021 18:09
To: i-d-annou...@ietf.org
Cc: lsr@ietf.org
Subject: [Lsr] I-D Action: draft-ietf-lsr-ospf-bfd-strict-mode-04.txt


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   : OSPF Strict-Mode for BFD
Authors : Ketan Talaulikar
  Peter Psenak
  Albert Fu
  Rajesh M
Filename: draft-ietf-lsr-ospf-bfd-strict-mode-04.txt
Pages   : 10
Date: 2021-10-22

Abstract:
   This document specifies the extensions to OSPF that enable an OSPF
   router to signal the requirement for a Bidirectional Forwarding
   Detection (BFD) session prior to adjacency formation.  Link-Local
   Signaling (LLS) is used to advertise the requirement of strict-mode
   for BFD session establishment for OSPF adjacency.  If both OSPF
   neighbors advertise the strict-mode for BFD, adjacency formation will
   be blocked until a BFD session has been successfully established.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-bfd-strict-mode/

There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospf-bfd-strict-mode-04

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-lsr-ospf-bfd-strict-mode-04


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 mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Proposed changes for OSPFv3 SRv6 encoding

[Ketan Talaulikar (ketant)]

Hi Dirk,

Your point is related to my original concern/interpretation for why we 
introduced a new LSA type for SRv6 Locator than use the existing Extended 
Prefix LSA types. This goes back to the original intention of the WG and 
authors of RFC8362.

If one can never generate the E-*-Prefix LSAs (e.g. E-Inter-Area-Prefix-LSA) 
without the presence/inclusion of their corresponding "base" 
prefix-reachability TLVs (e.g. Inter-Area-Prefix TLV), then these extended LSAs 
cannot be used for advertisement of SRv6 Locators in OSPFv3. This is because, 
for FlexAlgo we need the ability to advertise only the SRv6 Locators without 
the "base" prefix reachability.

I was made to understand, however, that the text in RFC8362 was only in the 
context of base OSPFv3 SPF and it was not intended to make the "base" prefix 
reachability TLVs mandatory in the extended LSAs. Hence the proposal for this 
change.

Would like to know the WG and RFC8362 authors views on this aspect.

Regd the NU bit, that applies for when Prefix SID mapping for an individual 
prefix is advertised by the SRMS by using the Prefix-SID sub-TLV inside the 
Intra/Inter/External Prefix TLVs. I was talking about the advertisement of 
ranges using the OSPFv3 Extended Prefix Range TLVs - there is no NU bit in the 
picture here AFAIK. I am referring to the text in 
https://datatracker.ietf.org/doc/html/rfc8666#section-8.1

Are you saying that implementations today are advertising say Intra-Area-Prefix 
TLV with NU bit set along with an OSPFv3 Extended Prefix Range TLV in the same 
E-Intra-Area-Prefix LSA for advertisement of SRMS ranges? If so, this was not 
very clear to me from RFC8666.

Thanks,
Ketan

From: Goethals, Dirk (Nokia - BE/Antwerp) 
Sent: 14 September 2021 14:15
To: Ketan Talaulikar (ketant) ; Ketan Talaulikar (ketant) 
; lsr@ietf.org
Subject: RE: Proposed changes for OSPFv3 SRv6 encoding

Hi Ketan,

I'm not sure I understand your reply correctly.
The same paragraph also mentions:


If the Inter-Area-Prefix TLV is not included in the E-Inter-Area-Prefix-LSA,

   it is treated as malformed as described in Section 
5<https://datatracker.ietf.org/doc/html/rfc8362#section-5>.

w.r.t OSPFv3 Extended Prefix Range TLV
I've been told that the NU-bit 
(https://datatracker.ietf.org/doc/html/rfc5340#appendix-A.4.1.1)
is used to exclude it from unicast.

I'm I missing something?
Thx,
Dirk

From: Ketan Talaulikar (ketant) mailto:ket...@cisco.com>>
Sent: Tuesday, September 14, 2021 9:56 AM
To: Goethals, Dirk (Nokia - BE/Antwerp) 
mailto:dirk.goeth...@nokia.com>>; Ketan Talaulikar 
(ketant) 
mailto:ketant=40cisco@dmarc.ietf.org>>; 
lsr@ietf.org<mailto:lsr@ietf.org>
Subject: RE: Proposed changes for OSPFv3 SRv6 encoding


Hi Dirk,



There was a misunderstanding of Acee's comment and its context on my part. More 
specifically my misunderstanding on what RFC8362 text intended to say.



E.g. https://datatracker.ietf.org/doc/html/rfc8362#section-4.3 says the 
following


   In order to retain
   compatibility and semantics with the current OSPFv3 specification,
   each Inter-Area-Prefix LSA MUST contain a single Inter-Area-Prefix
   TLV.



I read this as Inter-Area-Prefix TLV must be present in an OSPFv3 
E-Inter-Area-Prefix LSA and other TLVs may be added optionally. However, this 
does not seem to be the correct interpretation since we already have introduced 
the OSPFv3 Extended Prefix Range TLV in 
https://datatracker.ietf.org/doc/html/rfc8666#section-5 that is a top-level TLV 
and may be used for a prefix without its corresponding Inter-Area-Prefix TLV.



So we can introduce the SRv6 Locator TLV similar to the Prefix Range TLV into 
the existing Prefix LSAs as indicated by Acee and there would not be an issue.



Thanks,

Ketan



-Original Message-
From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of 
Goethals, Dirk (Nokia - BE/Antwerp)
Sent: 14 September 2021 12:58
To: Ketan Talaulikar (ketant) 
mailto:ketant=40cisco@dmarc.ietf.org>>; 
lsr@ietf.org<mailto:lsr@ietf.org>
Subject: Re: [Lsr] Proposed changes for OSPFv3 SRv6 encoding



Hi Ketan,

I'm not against this suggested change.

I noticed however, that Acee suggested this a while back and at that time you 
mentioned an issue when flex-algo locators where advertised this way, see snip 
below. Can you elaborate on why this is no longer an issue?

Thx,

Dirk





[Acee]

Why do you define a separate SRv6 Locator LSA to advertise SRv6 reachability? 
One of the primary benefits of RFC8362 is to advertise all the information 
associated with a prefix in one LSA. Now you have negated that benefit by 
putting this information in a separate LSA.

[KT] We need to define a new LSA since this is not an extension for the normal 
prefix reachability. For doing FlexAlgo with SRv6, the locators are used for 
reachability computation within the FlexAlgo. If these were advertised as 
normal prefix reachability then routers

Re: [Lsr] Proposed changes for OSPFv3 SRv6 encoding

[Ketan Talaulikar (ketant)]

Hi Dirk,



There was a misunderstanding of Acee's comment and its context on my part. More 
specifically my misunderstanding on what RFC8362 text intended to say.



E.g. https://datatracker.ietf.org/doc/html/rfc8362#section-4.3 says the 
following


   In order to retain
   compatibility and semantics with the current OSPFv3 specification,
   each Inter-Area-Prefix LSA MUST contain a single Inter-Area-Prefix
   TLV.



I read this as Inter-Area-Prefix TLV must be present in an OSPFv3 
E-Inter-Area-Prefix LSA and other TLVs may be added optionally. However, this 
does not seem to be the correct interpretation since we already have introduced 
the OSPFv3 Extended Prefix Range TLV in 
https://datatracker.ietf.org/doc/html/rfc8666#section-5 that is a top-level TLV 
and may be used for a prefix without its corresponding Inter-Area-Prefix TLV.



So we can introduce the SRv6 Locator TLV similar to the Prefix Range TLV into 
the existing Prefix LSAs as indicated by Acee and there would not be an issue.



Thanks,

Ketan



-Original Message-
From: Lsr  On Behalf Of Goethals, Dirk (Nokia - 
BE/Antwerp)
Sent: 14 September 2021 12:58
To: Ketan Talaulikar (ketant) ; lsr@ietf.org
Subject: Re: [Lsr] Proposed changes for OSPFv3 SRv6 encoding



Hi Ketan,

I'm not against this suggested change.

I noticed however, that Acee suggested this a while back and at that time you 
mentioned an issue when flex-algo locators where advertised this way, see snip 
below. Can you elaborate on why this is no longer an issue?

Thx,

Dirk





[Acee]

Why do you define a separate SRv6 Locator LSA to advertise SRv6 reachability? 
One of the primary benefits of RFC8362 is to advertise all the information 
associated with a prefix in one LSA. Now you have negated that benefit by 
putting this information in a separate LSA.

[KT] We need to define a new LSA since this is not an extension for the normal 
prefix reachability. For doing FlexAlgo with SRv6, the locators are used for 
reachability computation within the FlexAlgo. If these were advertised as 
normal prefix reachability then routers which are not part of the FlexAlgo or 
even routers not supporting SRv6 would program them. We've tried to explain 
this in 
https://tools.ietf.org/html/draft-li-ospf-ospfv3-srv6-extensions-07#section-5.





-Original Message-

From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of 
Ketan Talaulikar (ketant)

Sent: Monday, September 13, 2021 6:29 PM

To: lsr@ietf.org<mailto:lsr@ietf.org>

Subject: [Lsr] Proposed changes for OSPFv3 SRv6 encoding



Hello All,



Some feedback has been received with suggestions to change the encoding 
currently proposed in the draft - more specifically related to 
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospfv3-srv6-extensions-02#section-6



The proposal is to do away with the need for introduction of a new LSA for SRv6 
Locator and instead advertise the SRv6 Locator as a new top-level TLV within 
all the extended Prefix LSAs introduced in RFC8362. The advantage is simpler 
processing for the scenarios where the prefix is advertised as both a normal 
prefix reachability as well as SRv6 Locator. It also results in avoiding the 
handling of a new LSA type in OSPFv3.



I would like to poll the WG to check if there are any existing implementations 
of the draft in the current form (even though codepoints have not yet been 
allocated). Also, if there is any objection to introducing this change.



Thanks,

Ketan



___

Lsr mailing list

Lsr@ietf.org<mailto:Lsr@ietf.org>

https://www.ietf.org/mailman/listinfo/lsr



___

Lsr mailing list

Lsr@ietf.org<mailto:Lsr@ietf.org>

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

[Lsr] Proposed changes for OSPFv3 SRv6 encoding

[Ketan Talaulikar (ketant)]

Hello All,

Some feedback has been received with suggestions to change the encoding 
currently proposed in the draft - more specifically related to 
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospfv3-srv6-extensions-02#section-6

The proposal is to do away with the need for introduction of a new LSA for SRv6 
Locator and instead advertise the SRv6 Locator as a new top-level TLV within 
all the extended Prefix LSAs introduced in RFC8362. The advantage is simpler 
processing for the scenarios where the prefix is advertised as both a normal 
prefix reachability as well as SRv6 Locator. It also results in avoiding the 
handling of a new LSA type in OSPFv3.

I would like to poll the WG to check if there are any existing implementations 
of the draft in the current form (even though codepoints have not yet been 
allocated). Also, if there is any objection to introducing this change.

Thanks,
Ketan

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

Re: [Lsr] I-D Action: draft-ietf-lsr-flex-algo-bw-con-01.txt

[Ketan Talaulikar (ketant)]

Hi Les,

Just a short comment on the RSVP-TE part.

We do have a R bit for RSVP-TE in ASLA SABM so I don’t see the need for the 
advertisement under TLV 22 (et all) in ISIS.

Similar applies for OSPF too, but in that case, there is a separate TE Opaque 
LSA that is dedicated for RSVP-TE and hence advertisement as a sub-TLV there 
that may be considered (as per RFC8920). However, even in OSPF it doesn’t make 
sense to have it as application independent under the OSPFv2 Extended Link LSA 
as that is not really used by RSVP-TE today.

Thanks,
Ketan

From: Lsr  On Behalf Of Les Ginsberg (ginsberg)
Sent: 24 July 2021 00:48
To: Gyan Mishra ; Peter Psenak (ppsenak) 

Cc: gregory.mir...@ztetx.com; Ron Bonica ; Shraddha Hegde 
; draft-ietf-lsr-flex-algo-bw-con.auth...@ietf.org; 
lsr@ietf.org; Acee Lindem (acee) 
Subject: Re: [Lsr] I-D Action: draft-ietf-lsr-flex-algo-bw-con-01.txt

Gyan –

I do not see Generic Metric as an application independent link attribute.
It is an attribute that could be used by multiple applications – in which case 
you would advertise it in ASLA with the logical OR of all of the applications 
using it.

The only existing example of an application independent attribute is Maximum 
Link Bandwidth. This is an attribute of the physical link – independent of the 
application(s) which use it – in which case 
https://www.rfc-editor.org/rfc/rfc8919.html#section-4.2.1 applies.
If some other attribute is ever defined which has the same characteristic, then 
I would expect the same advertisement model to be used.

Metric – in all its forms (whether TE, Delay, or now Generic) – is not a 
property of the physical link. It is – as Peter has described - a value that is 
configured or computed to be used by one or more applications. I do not see the 
need to define an application independent method of advertising it.

If one believes that legacy applications such as RSVP-TE will be extended to 
support Generic Metric, then a valid argument can be made for supporting 
advertisement of Generic Metric as a direct sub-TLV in TLVs 22 et al as well as 
ASLA. I would be somewhat surprised if RSVP-TE were extended in this way, but 
that is up to the marketplace to decide.

   Les

From: Gyan Mishra mailto:hayabusa...@gmail.com>>
Sent: Friday, July 23, 2021 11:44 AM
To: Peter Psenak (ppsenak) mailto:ppse...@cisco.com>>
Cc: Acee Lindem (acee) mailto:a...@cisco.com>>; Les Ginsberg 
(ginsberg) mailto:ginsb...@cisco.com>>; Ron Bonica 
mailto:rbon...@juniper.net>>; Shraddha Hegde 
mailto:shrad...@juniper.net>>; 
draft-ietf-lsr-flex-algo-bw-con.auth...@ietf.org;
 gregory.mir...@ztetx.com; 
lsr@ietf.org
Subject: Re: [Lsr] I-D Action: draft-ietf-lsr-flex-algo-bw-con-01.txt


Peter

How would you advertise Generic metric link attribute in Flex Algo as both ASLA 
and application independent?

For ASLA you set the bit vector but application independent in ASLA what do you 
do?

Kind Regards

Gyan

On Fri, Jul 23, 2021 at 4:19 AM Peter Psenak 
mailto:40cisco@dmarc.ietf.org>> wrote:
Hi Ron,

keeping the normative statements aside.

We are defining a Generic Metric TLV.

1. The first and only defined usage at this point is for Flex-algo.

2. Generic Metric is not something that must be defined as application
independent, on the contrary, it's a value that is either assigned by
operator or computed somehow. Advertising application specific values
not only make sense, but would add value. TE metric is an example which
is very close to Generic Metric and is supported in ASLA.

3. Flex-algo is an application from the ASLA framework perspective and
so far is only using ASLA encoded link attributes. It would make sense
to continue to do so for Generic Metric.

4. If you feel you need the Generic Metric also as an application
independent value, I'm fine, although I do not see the immediate use case.

Given the above, would not you thing that advertising Generic Metric in
ASLA make sense?

thanks,
Peter








On 23/07/2021 06:13, Ron Bonica wrote:
> Les,
>
> Please, let us avoid discussion of whether my message is disingenuous. As 
> Acee will agree, discussion of my internal motivations and moral deficiencies 
> is beyond the scope of the LSR WG.
>
> Now, let us address my point and your counter points. My point was that 
> draft-ietf-lsr-flex-algo-bw-con does not violate RFC 8919. Nothing more, 
> nothing less.
>
> In your counterpoint #1, you point out tension between 
> draft-ietf-lsr-flex-algo-bw-con and draft-ietf-lsr-flex-algo. While this 
> point deserves discussion, it is orthogonal to my point. It is entirely 
> possible that both of the following statements are true:
>
> - draft-ietf-lsr-flex-algo-bw-con does not violate RFC 8919
> - there is tension between draft-ietf-lsr-flex-algo-bw-con and 
> draft-ietf-lsr-flex-algo
>
> In your counterpoint #2, you talk about the "clear intent" of RFC 8919. 
> Section 

Re: [Lsr] WG Last Call for IGP extension for PCEP security capability support in the PCE discovery - draft-ietf-lsr-pce-discovery-security-support-05

[Ketan Talaulikar (ketant)]

Hi Acee,

Indeed the mechanism for key rollover is well documented and widely implemented 
via configuration/provisioning methods.

My question was regarding how the specific steps/procedures as described in 
https://datatracker.ietf.org/doc/html/rfc8177#section-2.2 are going to get 
realized in this proposal where we have an IGP and PCEP protocols in operation.

To me the use of this mechanism in such dynamic and distributed routing 
protocol operations seems to be under-specified for a standards track document 
– not good enough for ensuring interoperable implementations.

Hope that clarifies and I’ll rest my case with that.

Thanks,
Ketan

From: Acee Lindem (acee) 
Sent: 23 July 2021 22:24
To: Ketan Talaulikar (ketant) ; lsr@ietf.org
Cc: draft-ietf-lsr-pce-discovery-security-supp...@ietf.org; p...@ietf.org
Subject: Re: WG Last Call for IGP extension for PCEP security capability 
support in the PCE discovery - draft-ietf-lsr-pce-discovery-security-support-05

Hi Ketan,

From: "Ketan Talaulikar (ketant)" 
mailto:ketant=40cisco@dmarc.ietf.org>>
Date: Friday, July 23, 2021 at 11:20 AM
To: Acee Lindem mailto:a...@cisco.com>>, 
"lsr@ietf.org<mailto:lsr@ietf.org>" mailto:lsr@ietf.org>>
Cc: 
"draft-ietf-lsr-pce-discovery-security-supp...@ietf.org<mailto:draft-ietf-lsr-pce-discovery-security-supp...@ietf.org>"
 
mailto:draft-ietf-lsr-pce-discovery-security-supp...@ietf.org>>,
 "p...@ietf.org<mailto:p...@ietf.org>" mailto:p...@ietf.org>>
Subject: RE: WG Last Call for IGP extension for PCEP security capability 
support in the PCE discovery - draft-ietf-lsr-pce-discovery-security-support-05

Hi Acee,

Agree about the keychain provisioning part.

The distribution via IGP for the key selections and the handling  of the same 
in PCEP sounded new to me. Is there any precedent for this? How does it all 
work actually and what is needed on the PCE and PCC to handle the 
change/transitions – this is all missing – probably needs a PCEP spec? This is 
many PCCs trying to connect to a PCE. I was trying to understand this better 
and how all that weighs against a potential for attack/disruption by someone 
doing a M-i-M or replay attack.

Roll-over of keys with key-chains is well-understood.

https://datatracker.ietf.org/doc/html/rfc8177#section-2.2

As is TCP-AO and TLS authentication. The only further specification required 
would the configuration in the PCE YANG model(s).

Thanks,
Acee

Just some questions … as this seemed something new to me and the spec does not 
provide any pointers.

Thanks,
Ketan

From: Acee Lindem (acee) 
mailto:acee=40cisco@dmarc.ietf.org>>
Sent: 23 July 2021 18:52
To: Ketan Talaulikar (ketant) mailto:ket...@cisco.com>>; 
lsr@ietf.org<mailto:lsr@ietf.org>
Cc: 
draft-ietf-lsr-pce-discovery-security-supp...@ietf.org<mailto:draft-ietf-lsr-pce-discovery-security-supp...@ietf.org>;
 p...@ietf.org<mailto:p...@ietf.org>
Subject: Re: WG Last Call for IGP extension for PCEP security capability 
support in the PCE discovery - draft-ietf-lsr-pce-discovery-security-support-05

Hi Ketan,

From: "Ketan Talaulikar (ketant)" 
mailto:ketant=40cisco@dmarc.ietf.org>>
Date: Friday, July 23, 2021 at 9:10 AM
To: Acee Lindem mailto:a...@cisco.com>>, 
"lsr@ietf.org<mailto:lsr@ietf.org>" mailto:lsr@ietf.org>>
Cc: 
"draft-ietf-lsr-pce-discovery-security-supp...@ietf.org<mailto:draft-ietf-lsr-pce-discovery-security-supp...@ietf.org>"
 
mailto:draft-ietf-lsr-pce-discovery-security-supp...@ietf.org>>,
 "p...@ietf.org<mailto:p...@ietf.org>" mailto:p...@ietf.org>>
Subject: RE: WG Last Call for IGP extension for PCEP security capability 
support in the PCE discovery - draft-ietf-lsr-pce-discovery-security-support-05

Hello All,

I have reviewed this draft and have the following comments for the authors to 
address and the WG to consider:


1) Is there any precedent for the advertisement of auth keychain info 
(ID/name) in such a manner that is flooded across the IGP domain? When the 
actual keychain anyway needs to be configured on all PCCs what is really the 
value in their advertisement other than possibly exposure to attack? I hope the 
security directorate reviewer looks at this closely and we get some early 
feedback specifically on this aspect.

The key-chain mechanism was standardized in RFC 8177 and is referenced by all 
the routing protocol YANG models. While key-chains, as well as, pre-shared keys 
need to be configured, having multiple configured key-chains that are 
selectable via discovery is obviously more operationally secure than having a 
single one.

Thanks,
Acee


2) In sec 3.2 and 3.3, new sub-TLVs are being introduced. Their ASCII art 
pictures represent the OSPF TLVs. The ISIS TLV structure is different. While 
this will be obvious to most in this WG, I would request this to be clarif

Re: [Lsr] WG Last Call for IGP extension for PCEP security capability support in the PCE discovery - draft-ietf-lsr-pce-discovery-security-support-05

[Ketan Talaulikar (ketant)]

Hi Acee,

Agree about the keychain provisioning part.

The distribution via IGP for the key selections and the handling  of the same 
in PCEP sounded new to me. Is there any precedent for this? How does it all 
work actually and what is needed on the PCE and PCC to handle the 
change/transitions – this is all missing – probably needs a PCEP spec? This is 
many PCCs trying to connect to a PCE. I was trying to understand this better 
and how all that weighs against a potential for attack/disruption by someone 
doing a M-i-M or replay attack.

Just some questions … as this seemed something new to me and the spec does not 
provide any pointers.

Thanks,
Ketan

From: Acee Lindem (acee) 
Sent: 23 July 2021 18:52
To: Ketan Talaulikar (ketant) ; lsr@ietf.org
Cc: draft-ietf-lsr-pce-discovery-security-supp...@ietf.org; p...@ietf.org
Subject: Re: WG Last Call for IGP extension for PCEP security capability 
support in the PCE discovery - draft-ietf-lsr-pce-discovery-security-support-05

Hi Ketan,

From: "Ketan Talaulikar (ketant)" 
mailto:ketant=40cisco@dmarc.ietf.org>>
Date: Friday, July 23, 2021 at 9:10 AM
To: Acee Lindem mailto:a...@cisco.com>>, 
"lsr@ietf.org<mailto:lsr@ietf.org>" mailto:lsr@ietf.org>>
Cc: 
"draft-ietf-lsr-pce-discovery-security-supp...@ietf.org<mailto:draft-ietf-lsr-pce-discovery-security-supp...@ietf.org>"
 
mailto:draft-ietf-lsr-pce-discovery-security-supp...@ietf.org>>,
 "p...@ietf.org<mailto:p...@ietf.org>" mailto:p...@ietf.org>>
Subject: RE: WG Last Call for IGP extension for PCEP security capability 
support in the PCE discovery - draft-ietf-lsr-pce-discovery-security-support-05

Hello All,

I have reviewed this draft and have the following comments for the authors to 
address and the WG to consider:


1) Is there any precedent for the advertisement of auth keychain info 
(ID/name) in such a manner that is flooded across the IGP domain? When the 
actual keychain anyway needs to be configured on all PCCs what is really the 
value in their advertisement other than possibly exposure to attack? I hope the 
security directorate reviewer looks at this closely and we get some early 
feedback specifically on this aspect.

The key-chain mechanism was standardized in RFC 8177 and is referenced by all 
the routing protocol YANG models. While key-chains, as well as, pre-shared keys 
need to be configured, having multiple configured key-chains that are 
selectable via discovery is obviously more operationally secure than having a 
single one.

Thanks,
Acee


2) In sec 3.2 and 3.3, new sub-TLVs are being introduced. Their ASCII art 
pictures represent the OSPF TLVs. The ISIS TLV structure is different. While 
this will be obvious to most in this WG, I would request this to be clarified – 
perhaps by introducing separate diagrams for both protocols or skipping the art 
altogether.

3) RFC5088 applies to both OSPFv2 and OSPFv3. This is however not clear in 
the text of this document.

4) Looks like RFC5088 asked for the PCE Capabilities Flags registry to be 
created as a top-level IANA OSPF registry - 
https://datatracker.ietf.org/doc/html/rfc5088#section-7.2 – so it should have 
been placed here : 
https://www.iana.org/assignments/ospf-parameters/ospf-parameters.xhtml. What 
seems to have happened is that it got created under OSPFv2 which is wrong - 
https://www.iana.org/assignments/ospfv2-parameters/ospfv2-parameters.xml#ospfv2-parameters-14.
 Since this draft updates RFC5088, it is necessary for this document to fix 
this error. I would support Les in that perhaps all of this (i.e. everything 
under/related to PCED TLV) ought to be moved under the IANA Common IGP registry 
here : https://www.iana.org/assignments/igp-parameters/igp-parameters.xhtml

5) The document needs to be more specific and clear about which IANA 
registries to be used to avoid errors that have happened in the past (see (3) 
above).

6) Appendix A, I believe what the authors intended here was that whether to 
use MD5 auth or not was part of discovery but static configuration on the PCE 
and PCC? The keychain introduced in this document can also be used along with 
MD5. Honestly, I don’t see a strong reason to not include MD5 in the signalling 
except that it is deprecated (even if widely deployed). This document would not 
conflict or contradict with RFC5440 if it did include a bit for MD5 support as 
well. As  follow-on, perhaps this document should also update RFC5440 – 
specifically for the security section? I see RFC8253 introducing TLS that 
updates RFC5440 but nothing that introduces TCP-AO?. In any case, these are 
aspects for PCE WG so I will leave those to the experts there.

Thanks,
Ketan

From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of Acee 
Lindem (acee)
Sent: 21 July 2021 22:16
To: lsr@ietf.org<mailto:lsr@ietf.org>
Cc: 
draft-ietf-lsr-pce-discovery-security-supp...@ietf.org<mailt

Re: [Lsr] WG Last Call for IGP extension for PCEP security capability support in the PCE discovery - draft-ietf-lsr-pce-discovery-security-support-05

[Ketan Talaulikar (ketant)]

Hello All,

I have reviewed this draft and have the following comments for the authors to 
address and the WG to consider:


  1.  Is there any precedent for the advertisement of auth keychain info 
(ID/name) in such a manner that is flooded across the IGP domain? When the 
actual keychain anyway needs to be configured on all PCCs what is really the 
value in their advertisement other than possibly exposure to attack? I hope the 
security directorate reviewer looks at this closely and we get some early 
feedback specifically on this aspect.
  2.  In sec 3.2 and 3.3, new sub-TLVs are being introduced. Their ASCII art 
pictures represent the OSPF TLVs. The ISIS TLV structure is different. While 
this will be obvious to most in this WG, I would request this to be clarified – 
perhaps by introducing separate diagrams for both protocols or skipping the art 
altogether.
  3.  RFC5088 applies to both OSPFv2 and OSPFv3. This is however not clear in 
the text of this document.
  4.  Looks like RFC5088 asked for the PCE Capabilities Flags registry to be 
created as a top-level IANA OSPF registry - 
https://datatracker.ietf.org/doc/html/rfc5088#section-7.2 – so it should have 
been placed here : 
https://www.iana.org/assignments/ospf-parameters/ospf-parameters.xhtml. What 
seems to have happened is that it got created under OSPFv2 which is wrong - 
https://www.iana.org/assignments/ospfv2-parameters/ospfv2-parameters.xml#ospfv2-parameters-14.
 Since this draft updates RFC5088, it is necessary for this document to fix 
this error. I would support Les in that perhaps all of this (i.e. everything 
under/related to PCED TLV) ought to be moved under the IANA Common IGP registry 
here : https://www.iana.org/assignments/igp-parameters/igp-parameters.xhtml
  5.  The document needs to be more specific and clear about which IANA 
registries to be used to avoid errors that have happened in the past (see (3) 
above).
  6.  Appendix A, I believe what the authors intended here was that whether to 
use MD5 auth or not was part of discovery but static configuration on the PCE 
and PCC? The keychain introduced in this document can also be used along with 
MD5. Honestly, I don’t see a strong reason to not include MD5 in the signalling 
except that it is deprecated (even if widely deployed). This document would not 
conflict or contradict with RFC5440 if it did include a bit for MD5 support as 
well. As  follow-on, perhaps this document should also update RFC5440 – 
specifically for the security section? I see RFC8253 introducing TLS that 
updates RFC5440 but nothing that introduces TCP-AO?. In any case, these are 
aspects for PCE WG so I will leave those to the experts there.

Thanks,
Ketan

From: Lsr  On Behalf Of Acee Lindem (acee)
Sent: 21 July 2021 22:16
To: lsr@ietf.org
Cc: draft-ietf-lsr-pce-discovery-security-supp...@ietf.org
Subject: [Lsr] WG Last Call for IGP extension for PCEP security capability 
support in the PCE discovery - draft-ietf-lsr-pce-discovery-security-support-05

This begins a 3-week WG Last Call, ending on August 4th, 2021, for 
draft-ietf-lsr-pce-discovery-security-support. Please indicate your support or 
objection to this list before the end of the WG last call. The longer WG last 
call is to account for IETF week.

  
https://datatracker.ietf.org/doc/draft-ietf-lsr-pce-discovery-security-support/


Thanks,
Acee


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

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

[Ketan Talaulikar (ketant)]

Hello All,

I support the adoption of these drafts. This work is required to provide the 
necessary manageability YANG models for the equivalent protocol extension WG 
drafts.

Thanks,
Ketan

-Original Message-
From: Lsr  On Behalf Of Christian Hopps
Sent: 22 July 2021 16:18
To: lsr@ietf.org
Cc: lsr-cha...@ietf.org; lsr-...@ietf.org; cho...@chopps.org
Subject: [Lsr] LSR WG Adoption Call for SRv6 YANG drafts


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] I-D Action: draft-ietf-lsr-flex-algo-bw-con-01.txt

[Ketan Talaulikar (ketant)]

Hi Shraddha,



Thanks for your detailed email explanation.



I was one of the WG members who indicated that Generic Metric not be advertised 
in the base as well as ASLA encodings. But what you've missed out was that I 
asked for it to be used in ASLA alone and not as application independent.



Generic metric not only allows advertisement of existing IGP metric types but 
also introduces new ones e.g. Bandwidth. There will be others/more. We 
definitely do need the ability to have application specific values for these 
various Generic Metric types. One use-case is that there be a different 
reference b/w or threshold yardstick for FlexAlgo and SR Policy. The 
appl-independent proposal will require the specification and provisioning of 
new/additional user-defined Generic Metric types - potentially one per 
application (more if we consider different flex-algo) when we need different TE 
or B/W metric value per application. While advertising it in ASLA allows the 
same b/w metric type to be used with different values for FlexAlgo and SR 
Policy.



Regarding the ASLA encoding, there is nothing that prevents the same Generic 
Metric type/value being shared across applications. We have already 
implementations that do so for FlexAlgo. This is a solved problem.



Therefore, I still do believe that Generic Metric is application specific - as 
was originally in the draft version that the WG adopted.



Coming to Generic Metric in BGP, I agree with the use-case. However, that is 
orthogonal to how it is advertised in IGPs. On the contrary, having too many 
user-defined and standard Generic Metric types (as you've proposed) make things 
more challenging to reconcile at the BGP level when we have a mix of types.



Like other WG members, I do still believe that Generic Metric advertisement in 
ASLA *alone* would be the right way to go as far as having an extensible and 
generic encoding approach for the IGPs.



Thank,

Ketan



-Original Message-
From: Lsr  On Behalf Of Shraddha Hegde
Sent: 19 July 2021 23:35
To: gregory.mir...@ztetx.com; ppsenak=40cisco@dmarc.ietf.org; lsr@ietf.org
Cc: Les Ginsberg (ginsberg) ; 
draft-ietf-lsr-flex-algo-bw-con.auth...@ietf.org
Subject: Re: [Lsr] I-D Action: draft-ietf-lsr-flex-algo-bw-con-01.txt



Hi All,



Generic metric was allowed to be advertised in TLV 22/ ELO LSA as well as ASLA 
TLV before the draft was called for adoption.

During the recent WG adoption review, it was pointed out that ASLA architecture 
does not allow an attribute to be advertised in both application-specific and 
application-independent manner.



As a result of this Generic metric has been made an application-independent 
attribute in the latest version.

The reasons are below



1.Generic metric is required to be advertised in an application-independent 
manner that is metric-type 128 is advertised for a link and any application 
like flex-algo, SR-TE, RSVP LFA can make use of it.

Metric has scope outside of an IGP domain. It gets advertised in BGP-LU and 
gets accumulated across domains.

There are many usecases that will benefit from advertising generic-metric in an 
application-independent manner.



2.The recent case of te-metric usecase that I came across where ASLA was being 
used, really wanted to use a different metric-type for flex-algo and not really 
different values for same metric type.

(Peter, coincidently we may be talking of the same recent usecase which you 
claimed to be using ASLA)



3.Advertising generic metric in an application independent manner in legacy TLV 
22 and ELO LSA does not violate RFC 8919/8920. Application-independent 
attributes are not expected to use RFC 8919/8920 mechanisms. Generic metric is 
like igp cost. IGP-cost is never advertised in ASLA but it gets used in 
flex-algo and generic-metric is being modeled based on igp-cost.

As currently written, this document is compliant to every RFC and draft that 
has been out there and not violating any of them.



4.Generic metric is very flexible. It allows for finest granularity of metric 
advertisement.

Usecase:

Lets say flex-algo 128 wants to use metric-type 128 and flex-algo 129 wants to 
use metric-type 129. An year later operator decides to deploy SR-TE with red 
LSPs using metric-type 128 and Blue LSPs using metric-type 129.

Using generic metric in application-independent manner:

1.configure metric-type 128 and 129 and value pair on each link 2. set 
flex-algo 128 FAD to use metric-type 128 and flex-algo FAD 129 to use 
metric-type 129 3. An year later configure Red LSPs to use metric-type 128 and 
Blue LSPs to use metric-type 129



Using generic metric with ASLA:

1. Define user defined bit-masks for flex-algo 128 and flex-algo 129 and 
configure on every router 2. configure metric-type 128 and 129 on every link 3. 
An year later, define user defined bit masks  for SR-TE Red LSPs and SR-TE blue 
LSPs 4. Configure the bit masks on all head-end routers 5. Associate the new 
bit masks with 

Re: [Lsr] Second Working Last Call for draft-ietf-lsr-flex-algo

[Ketan Talaulikar (ketant)]

Hi Acee/All,

I am not aware of any undisclosed IPR related to this draft.

Thanks,
Ketan

From: Acee Lindem (acee) 
Sent: 16 June 2021 19:31
To: lsr@ietf.org
Cc: Christian Hopps ; lsr-...@ietf.org; 
draft-ietf-lsr-flex-algo@ietf.org
Subject: Second Working Last Call for draft-ietf-lsr-flex-algo

After the first successful WG last call, the authors discovered that some 
re-work was needed for OSPF AS External route calculation – specifically with 
respect to the Flex Algorithm ASBR metrics and calculation. This was fixed and 
there were clarifications in the IANA section (see versions -14 and -15). The 
draft has been stable since April and we are now ready to WG last call the 
updated version.


Without further ado, this begins a 2 week WG Last Call, ending on July 1st, 
2021, for draft-ietf-lsr-flex-algo

  https://datatracker.ietf.org/doc/draft-ietf-lsr-flex-algo/

All authors, please indicate by sending an email to the list, whether you aware 
of any other IPR beyond what is already posted:

  [From 
https://datatracker.ietf.org/ipr/search/?submit=draft=draft-ietf-lsr-flex-algo]

  https://datatracker.ietf.org/ipr/3910/
  https://datatracker.ietf.org/ipr/3248/

Thanks,
Chris & Acee.


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

Re: [Lsr] LSR WG Adoption Call for "Algorithm Related IGP-Adjacency SID Advertisement"

[Ketan Talaulikar (ketant)]

Hi Gyan,

By the logic that you have shared, almost all OSPF RFCs after 2328 would have 
been mentioned as “updates” for it. However, there is only a select few that 
“update” RFC 2328 and if we look at them closely, they alter/change the 
contents of behavior in RFC 2328 in some way. At least that is my understanding.

From what I’ve seen, there does not seem to be a notion of “add on update”; 
only “change update”. Again, just my understanding.

In any case, we’ve recently seen another debate on “updates” in this WG that 
also included the IESG members. Hopefully something more formal will emerge 
from the community to clarify the use of “updates”.

Thanks,
Ketan

From: Gyan Mishra 
Sent: 11 June 2021 05:46
To: Ketan Talaulikar (ketant) 
Cc: cho...@chopps.org; lsr@ietf.org; peng.sha...@zte.com.cn
Subject: Re: [Lsr] LSR WG Adoption Call for "Algorithm Related IGP-Adjacency 
SID Advertisement"


Hi Ketan

In some cases an RFC can update an existing RFC making the other obsolete if 
the specification changes completely rewrite in the update, however an update 
could also as you pointed out in this case be an add on feature to a base 
specification that is not changing and so in this case the Flex Algo base 
specification and this draft is an add on update not a change update  to the 
base specification.

Example

OSPFv2

RFC 1583 2178 2328 - 2328 is updated base that obsoletes the previous 
specifications

RFC add on updates to base 2328
5709 6549 6845 6860 7074 8042

So in this case this draft would be an add on update to the base Flex Algo 
draft is what I was thinking.

Kind Regards

Gyan

On Thu, Jun 10, 2021 at 11:09 AM Ketan Talaulikar (ketant) 
mailto:ket...@cisco.com>> wrote:
Hi Gyan,

This document does not even “update” the LSR Flex-Algo draft since it is 
introducing something new and on top. It does not change what’s in the LSR 
Flex-Algo draft.

This document would be pretty much independent and an optional/add-on element 
on top of the LSR Flex-Algo solution.

Thanks,
Ketan

From: Gyan Mishra mailto:hayabusa...@gmail.com>>
Sent: 10 June 2021 18:54
To: Ketan Talaulikar (ketant) mailto:ket...@cisco.com>>
Cc: cho...@chopps.org<mailto:cho...@chopps.org>; 
lsr@ietf.org<mailto:lsr@ietf.org>; 
peng.sha...@zte.com.cn<mailto:peng.sha...@zte.com.cn>
Subject: Re: [Lsr] LSR WG Adoption Call for "Algorithm Related IGP-Adjacency 
SID Advertisement"


Hi Ketan

See in-line

Thanks

Gyan

On Thu, Jun 10, 2021 at 4:40 AM Ketan Talaulikar (ketant) 
mailto:ket...@cisco.com>> wrote:
One quick clarification on the following:

Does this draft update the SR IGP extensions for SR-MPLS RFC 8665 8666 8667.
[PSF] Yes.
KT> This draft proposes something new (an Algo-specific Adj-SID) and their 
relevant signalling extensions for the IGPs. It does not change anything in the 
RFCs referred to above. Hence there is no "updates" consideration here.

Gyan>This is a confusing point and maybe something the authors can clarify 
in the text.  So this  draft defines a new Adj-Sid that has an Algo identifier 
specifically for Flex Algo and if that’s the case I agree it does not update 
the SR-MPLS IGP extensions, but instead should update the Flex Algo extensions.


Thanks,
Ketan

-Original Message-
From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of 
peng.sha...@zte.com.cn<mailto:peng.sha...@zte.com.cn>
Sent: 10 June 2021 11:48
To: hayabusa...@gmail.com<mailto:hayabusa...@gmail.com>
Cc: lsr@ietf.org<mailto:lsr@ietf.org>; 
cho...@chopps.org<mailto:cho...@chopps.org>
Subject: Re: [Lsr] LSR WG Adoption Call for "Algorithm Related IGP-Adjacency 
SID Advertisement"

Hi Gyan,

Thanks for your support.
Please see inline [PSF]

Regards,
PSF


--原始邮件--
发件人：GyanMishra
收件人：Christian Hopps;
抄送人：lsr@ietf.org<mailto:lsr@ietf.org>;
日 期 ：2021年06月10日 13:05
主 题 ：Re: [Lsr] LSR WG Adoption Call for "Algorithm Related IGP-Adjacency SID 
Advertisement"
___
Lsr mailing list
Lsr@ietf.org<mailto:Lsr@ietf.org>
https://www.ietf.org/mailman/listinfo/lsr


I support WG adoption of this draft.

This draft fills the gap where multiple algorithm identifiers are associated 
with a link applied to prefix sid and to add parity as now this draft provides 
Algo association with the adjacency SID as well.  At the end of the 
introduction is stated that the algorithm identifier should be included as part 
of the adjacency SID advertisement for SR-MPLS.   What about SRv6?

[PSF] For SRv6, tt was born with this ability, since SRv6 END.X SID can be 
allocated from an algorithm specific Locator.


Does this draft update the SR IGP extensions for SR-MPLS RFC 8665 8666 8667.

[PSF] Yes.


Also does it update the Flex Algo draft?
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-flex-algo-16

[PSF] No.


In section 5 operations describes how f

Re: [Lsr] LSR WG Adoption Call for "Algorithm Related IGP-Adjacency SID Advertisement"

[Ketan Talaulikar (ketant)]

Hi Gyan,

This document does not even “update” the LSR Flex-Algo draft since it is 
introducing something new and on top. It does not change what’s in the LSR 
Flex-Algo draft.

This document would be pretty much independent and an optional/add-on element 
on top of the LSR Flex-Algo solution.

Thanks,
Ketan

From: Gyan Mishra 
Sent: 10 June 2021 18:54
To: Ketan Talaulikar (ketant) 
Cc: cho...@chopps.org; lsr@ietf.org; peng.sha...@zte.com.cn
Subject: Re: [Lsr] LSR WG Adoption Call for "Algorithm Related IGP-Adjacency 
SID Advertisement"


Hi Ketan

See in-line

Thanks

Gyan

On Thu, Jun 10, 2021 at 4:40 AM Ketan Talaulikar (ketant) 
mailto:ket...@cisco.com>> wrote:
One quick clarification on the following:

Does this draft update the SR IGP extensions for SR-MPLS RFC 8665 8666 8667.
[PSF] Yes.
KT> This draft proposes something new (an Algo-specific Adj-SID) and their 
relevant signalling extensions for the IGPs. It does not change anything in the 
RFCs referred to above. Hence there is no "updates" consideration here.

Gyan>This is a confusing point and maybe something the authors can clarify 
in the text.  So this  draft defines a new Adj-Sid that has an Algo identifier 
specifically for Flex Algo and if that’s the case I agree it does not update 
the SR-MPLS IGP extensions, but instead should update the Flex Algo extensions.


Thanks,
Ketan

-Original Message-
From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of 
peng.sha...@zte.com.cn<mailto:peng.sha...@zte.com.cn>
Sent: 10 June 2021 11:48
To: hayabusa...@gmail.com<mailto:hayabusa...@gmail.com>
Cc: lsr@ietf.org<mailto:lsr@ietf.org>; 
cho...@chopps.org<mailto:cho...@chopps.org>
Subject: Re: [Lsr] LSR WG Adoption Call for "Algorithm Related IGP-Adjacency 
SID Advertisement"

Hi Gyan,

Thanks for your support.
Please see inline [PSF]

Regards,
PSF


--原始邮件--
发件人：GyanMishra
收件人：Christian Hopps;
抄送人：lsr@ietf.org<mailto:lsr@ietf.org>;
日 期 ：2021年06月10日 13:05
主 题 ：Re: [Lsr] LSR WG Adoption Call for "Algorithm Related IGP-Adjacency SID 
Advertisement"
___
Lsr mailing list
Lsr@ietf.org<mailto:Lsr@ietf.org>
https://www.ietf.org/mailman/listinfo/lsr


I support WG adoption of this draft.

This draft fills the gap where multiple algorithm identifiers are associated 
with a link applied to prefix sid and to add parity as now this draft provides 
Algo association with the adjacency SID as well.  At the end of the 
introduction is stated that the algorithm identifier should be included as part 
of the adjacency SID advertisement for SR-MPLS.   What about SRv6?

[PSF] For SRv6, tt was born with this ability, since SRv6 END.X SID can be 
allocated from an algorithm specific Locator.


Does this draft update the SR IGP extensions for SR-MPLS RFC 8665 8666 8667.

[PSF] Yes.


Also does it update the Flex Algo draft?
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-flex-algo-16

[PSF] No.


In section 5 operations describes how flex Algo plane can now be differentiated 
on the same  adjacency link with the Algo identifier adjacency sid to Algo 
plane can now have QOS and link resources characteristics defined which maybe 
beneficial to TEAS network slicing application as well as used in conjunction 
with a resource sid for underlay resource provisioning for Enhanced VPN overlay.

[PSF] Agree. Flex-algo can be used alone as a network slicing mechanism for 
some limited scenarios, and adj-sid per algo provide a basis for this purpose. 
However this is outside the scope of this document, so it is not described in 
detailed.


Kind Regards

Gyan

On Wed, May 26, 2021 at 5:00 PM Christian Hopps 
mailto:cho...@chopps.org>> wrote:

Hi Folks,

This begins a 2 week WG Adoption Call for the following draft:

https://datatracker.ietf.org/doc/draft-peng-lsr-algorithm-related-adjacency-sid/

Please indicate your support or objections by June 9th, 2021

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

Thanks,
Acee and Chris.

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

--

Gyan Mishra
Network Solutions Architect
Email gyan.s.mis...@verizon.com<mailto:gyan.s.mis...@verizon.com>
M 301 502-1347
--

[http://ss7.vzw.com/is/image/VerizonWireless/vz-logo-email]<http://www.verizon.com/>

Gyan Mishra

Network Solutions Architect

Email gyan.s.mis...@verizon.com<mailto:gyan.s.mis...@verizon.com>

M 301 502-1347

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

Re: [Lsr] LSR WG Adoption Call for "Algorithm Related IGP-Adjacency SID Advertisement"

[Ketan Talaulikar (ketant)]

One quick clarification on the following:

Does this draft update the SR IGP extensions for SR-MPLS RFC 8665 8666 8667.
[PSF] Yes.
KT> This draft proposes something new (an Algo-specific Adj-SID) and their 
relevant signalling extensions for the IGPs. It does not change anything in the 
RFCs referred to above. Hence there is no "updates" consideration here.

Thanks,
Ketan

-Original Message-
From: Lsr  On Behalf Of peng.sha...@zte.com.cn
Sent: 10 June 2021 11:48
To: hayabusa...@gmail.com
Cc: lsr@ietf.org; cho...@chopps.org
Subject: Re: [Lsr] LSR WG Adoption Call for "Algorithm Related IGP-Adjacency 
SID Advertisement"

Hi Gyan,

Thanks for your support.
Please see inline [PSF]

Regards,
PSF


--原始邮件--
发件人：GyanMishra
收件人：Christian Hopps;
抄送人：lsr@ietf.org;
日 期 ：2021年06月10日 13:05
主 题 ：Re: [Lsr] LSR WG Adoption Call for "Algorithm Related IGP-Adjacency SID 
Advertisement"
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr


I support WG adoption of this draft.

This draft fills the gap where multiple algorithm identifiers are associated 
with a link applied to prefix sid and to add parity as now this draft provides 
Algo association with the adjacency SID as well.  At the end of the 
introduction is stated that the algorithm identifier should be included as part 
of the adjacency SID advertisement for SR-MPLS.   What about SRv6?

[PSF] For SRv6, tt was born with this ability, since SRv6 END.X SID can be 
allocated from an algorithm specific Locator.


Does this draft update the SR IGP extensions for SR-MPLS RFC 8665 8666 8667.

[PSF] Yes.


Also does it update the Flex Algo draft?
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-flex-algo-16

[PSF] No.


In section 5 operations describes how flex Algo plane can now be differentiated 
on the same  adjacency link with the Algo identifier adjacency sid to Algo 
plane can now have QOS and link resources characteristics defined which maybe 
beneficial to TEAS network slicing application as well as used in conjunction 
with a resource sid for underlay resource provisioning for Enhanced VPN overlay.

[PSF] Agree. Flex-algo can be used alone as a network slicing mechanism for 
some limited scenarios, and adj-sid per algo provide a basis for this purpose. 
However this is outside the scope of this document, so it is not described in 
detailed. 


Kind Regards

Gyan

On Wed, May 26, 2021 at 5:00 PM Christian Hopps  wrote:

Hi Folks,

This begins a 2 week WG Adoption Call for the following draft:

https://datatracker.ietf.org/doc/draft-peng-lsr-algorithm-related-adjacency-sid/

Please indicate your support or objections by June 9th, 2021

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

Thanks,
Acee and Chris.

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

--

Gyan Mishra
Network Solutions Architect
Email gyan.s.mis...@verizon.com
M 301 502-1347
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

[Ketan Talaulikar (ketant)]

Hi Shraddha,

My point is that Generic Metric is not a legacy advertisement and it is 
application specific. Therefore, the place to advertise it is within the ASLA 
Sub-TLV - this applies to both ISIS and OSPF.

The references in RFC8919 and RFC8920 are about legacy advertisements and do 
not apply in this discussion.

Thanks,
Ketan

From: Shraddha Hegde 
Sent: 31 May 2021 14:20
To: Ketan Talaulikar (ketant) ; Tony Li 
Cc: Acee Lindem (acee) ; lsr@ietf.org; 
draft-hegde-lsr-flex-algo-bw-...@ietf.org
Subject: RE: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, 
Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

Hi Ketan,

Pls see inline..



Juniper Business Use Only
From: Ketan Talaulikar (ketant) mailto:ket...@cisco.com>>
Sent: Monday, May 31, 2021 1:14 PM
To: Shraddha Hegde mailto:shrad...@juniper.net>>; Tony Li 
mailto:tony...@tony.li>>
Cc: Acee Lindem (acee) 
mailto:acee=40cisco@dmarc.ietf.org>>; 
lsr@ietf.org<mailto:lsr@ietf.org>; 
draft-hegde-lsr-flex-algo-bw-...@ietf.org<mailto:draft-hegde-lsr-flex-algo-bw-...@ietf.org>
Subject: RE: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, 
Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

[External Email. Be cautious of content]

Hi Shraddha,

When you refer to "a single TE application", it is not clear which one you are 
referring to : RSVP-TE or SR Policy?
 It could be either of them

I believe, for ISIS, you are referring to this specific section of RFC8919 : 
https://datatracker.ietf.org/doc/html/rfc8919#section-6.1<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc8919*section-6.1__;Iw!!NEt6yMaO-gk!SmTMzCQguIxq18G34Q8h8vAc4v75zCvy8nJTn9lDqVb5ILlVa8hk81_AdZHekgKS$>

There is no ambiguity here. This section is about use of "legacy" 
advertisement. The Generic Metric is a new TLV and hence cannot be considered 
as "legacy" by any interpretation of the word.
 For ISIS, I hope you agree that generic metric sub-TLV is allowed to 
get advertised under TLV 22.

Coming to OSPF, the considerations are similar. Additionally we also have to 
deal with different LSA types here.

Please refer to 
https://datatracker.ietf.org/doc/html/rfc8920#section-12.1<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc8920*section-12.1__;Iw!!NEt6yMaO-gk!SmTMzCQguIxq18G34Q8h8vAc4v75zCvy8nJTn9lDqVb5ILlVa8hk81_Adc5YCVr4$>
 for the equivalent discussion for OSPF. This section is about "legacy" 
advertisements being in (RSVP) TE Opaque LSAs. If the TE application that you 
were referring to was RSVP-TE, then there is also additional guidance provided 
here : 
https://datatracker.ietf.org/doc/html/rfc8920#section-12.2.4<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc8920*section-12.2.4__;Iw!!NEt6yMaO-gk!SmTMzCQguIxq18G34Q8h8vAc4v75zCvy8nJTn9lDqVb5ILlVa8hk81_AdRkvFDI2$>


Please clarify where RFC8920 describes advertisement of application-specific 
attributes in say OSPFv2 Extended Link LSA other than within the ASLA sub-TLV.
 From what I understand, you agree that the generic metric sub-TLV 
should be allowed in TE Opaque LSA.
You have concerns only on it being allowed in Extended Link opaque LSA top 
level Extended Link TLV right?



Thanks,
Ketan

From: Shraddha Hegde mailto:shrad...@juniper.net>>
Sent: 31 May 2021 09:13
To: Ketan Talaulikar (ketant) mailto:ket...@cisco.com>>; Tony 
Li mailto:tony...@tony.li>>
Cc: Acee Lindem (acee) 
mailto:acee=40cisco@dmarc.ietf.org>>; 
lsr@ietf.org<mailto:lsr@ietf.org>; 
draft-hegde-lsr-flex-algo-bw-...@ietf.org<mailto:draft-hegde-lsr-flex-algo-bw-...@ietf.org>
Subject: RE: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, 
Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

Ketan,


Networks that deploy a single TE application and already advertising and using 
attributes from top level TLVs
Will benefit from new attributes also coming in the same top level TLVs. There 
is no confusion and ambiguity
from a network operators perspective and IMO this must be allowed in the 
protocol.

If the attribute gets advertised in both ASLA and top level TLV, how the 
receiver should process it, has been
described in RFC 8919 and 8920 and this draft will refer to the same procedures.
If you think there is ambiguity in RFC 8919 and RFC 8920, pls provide specific 
cases that are ambiguous.

Rgds
Shraddha



Juniper Business Use Only
From: Ketan Talaulikar (ketant) mailto:ket...@cisco.com>>
Sent: Thursday, May 27, 2021 7:13 PM
To: Shraddha Hegde mailto:shrad...@juniper.net>>; Tony Li 
mailto:tony...@tony.li>>
Cc: Acee Lindem (acee) 
mailto:acee=40cisco@dmarc.ietf.org>>; 
lsr@ietf.org<mailto:lsr@ietf.org>; 
draft-hegde-lsr-flex-algo-bw-...@ietf.org<mailto:draft-hegde-lsr-flex-algo-bw-...@ietf.org&g

Re: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

[Ketan Talaulikar (ketant)]

Hi Shraddha,

When you refer to "a single TE application", it is not clear which one you are 
referring to : RSVP-TE or SR Policy?

I believe, for ISIS, you are referring to this specific section of RFC8919 : 
https://datatracker.ietf.org/doc/html/rfc8919#section-6.1

There is no ambiguity here. This section is about use of "legacy" 
advertisement. The Generic Metric is a new TLV and hence cannot be considered 
as "legacy" by any interpretation of the word.

Coming to OSPF, the considerations are similar. Additionally we also have to 
deal with different LSA types here.

Please refer to https://datatracker.ietf.org/doc/html/rfc8920#section-12.1 for 
the equivalent discussion for OSPF. This section is about "legacy" 
advertisements being in (RSVP) TE Opaque LSAs. If the TE application that you 
were referring to was RSVP-TE, then there is also additional guidance provided 
here : https://datatracker.ietf.org/doc/html/rfc8920#section-12.2.4

Please clarify where RFC8920 describes advertisement of application-specific 
attributes in say OSPFv2 Extended Link LSA other than within the ASLA sub-TLV.

Thanks,
Ketan

From: Shraddha Hegde 
Sent: 31 May 2021 09:13
To: Ketan Talaulikar (ketant) ; Tony Li 
Cc: Acee Lindem (acee) ; lsr@ietf.org; 
draft-hegde-lsr-flex-algo-bw-...@ietf.org
Subject: RE: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, 
Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

Ketan,


Networks that deploy a single TE application and already advertising and using 
attributes from top level TLVs
Will benefit from new attributes also coming in the same top level TLVs. There 
is no confusion and ambiguity
from a network operators perspective and IMO this must be allowed in the 
protocol.

If the attribute gets advertised in both ASLA and top level TLV, how the 
receiver should process it, has been
described in RFC 8919 and 8920 and this draft will refer to the same procedures.
If you think there is ambiguity in RFC 8919 and RFC 8920, pls provide specific 
cases that are ambiguous.

Rgds
Shraddha



Juniper Business Use Only
From: Ketan Talaulikar (ketant) mailto:ket...@cisco.com>>
Sent: Thursday, May 27, 2021 7:13 PM
To: Shraddha Hegde mailto:shrad...@juniper.net>>; Tony Li 
mailto:tony...@tony.li>>
Cc: Acee Lindem (acee) 
mailto:acee=40cisco@dmarc.ietf.org>>; 
lsr@ietf.org<mailto:lsr@ietf.org>; 
draft-hegde-lsr-flex-algo-bw-...@ietf.org<mailto:draft-hegde-lsr-flex-algo-bw-...@ietf.org>
Subject: RE: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, 
Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

[External Email. Be cautious of content]

Hi Shraddha,

This is a new attribute that we are introducing and we are saying that it has 
application specific semantics. We now have the ASLA mechanics defined in both 
OSPF and ISIS. So why should it not use just the ASLA encoding?

Allowing its advertisement in the existing top-level TLVs in addition to ASLA 
introduces ambiguity for which applications can use it - we get into 
complications that are entirely avoidable.

Thanks,
Ketan

From: Shraddha Hegde mailto:shrad...@juniper.net>>
Sent: 27 May 2021 18:36
To: Ketan Talaulikar (ketant) mailto:ket...@cisco.com>>; Tony 
Li mailto:tony...@tony.li>>
Cc: Acee Lindem (acee) 
mailto:acee=40cisco@dmarc.ietf.org>>; 
lsr@ietf.org<mailto:lsr@ietf.org>; 
draft-hegde-lsr-flex-algo-bw-...@ietf.org<mailto:draft-hegde-lsr-flex-algo-bw-...@ietf.org>
Subject: RE: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, 
Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

Snipped..


  1.  Since the draft is covering FlexAlgo, I would have expected that Generic 
Metric is carried only in the ASLA and this document specifies usage only for 
the FA application. Later this can be also used/extended for other applications 
but still within ASLA. Keeping an option of advertising both outside and within 
the ASLA is problematic - we will need precedence rules and such. I prefer we 
avoid this complication.


We preferred avoiding ASLA.
[KT] The text today does not avoid ASLA and in fact requires the use of ASLA 
(quite correctly) for FlexAlgo application. Peter has confirmed the same. I am 
simply asking to avoid the complications of using Generic Metric in both ASLA 
and outside it. Whatever new "application" we invent to use this generic metric 
type, can use ASLA so that the Generic Metric can be very cleanly shared 
between applications. The encoding allows for using the same value - sharing 
single advertisement across applications or doing a different one 
per-application.
 Generic metric is allowed in ASLA, it is also allowed in all 
traditional TLVs/LSAs where link attributes are advertised.
This is required so that all the applications, existing and new can make use of

Re: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

[Ketan Talaulikar (ketant)]

Hi Shraddha,

This is a new attribute that we are introducing and we are saying that it has 
application specific semantics. We now have the ASLA mechanics defined in both 
OSPF and ISIS. So why should it not use just the ASLA encoding?

Allowing its advertisement in the existing top-level TLVs in addition to ASLA 
introduces ambiguity for which applications can use it - we get into 
complications that are entirely avoidable.

Thanks,
Ketan

From: Shraddha Hegde 
Sent: 27 May 2021 18:36
To: Ketan Talaulikar (ketant) ; Tony Li 
Cc: Acee Lindem (acee) ; lsr@ietf.org; 
draft-hegde-lsr-flex-algo-bw-...@ietf.org
Subject: RE: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, 
Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

Snipped..


  1.  Since the draft is covering FlexAlgo, I would have expected that Generic 
Metric is carried only in the ASLA and this document specifies usage only for 
the FA application. Later this can be also used/extended for other applications 
but still within ASLA. Keeping an option of advertising both outside and within 
the ASLA is problematic - we will need precedence rules and such. I prefer we 
avoid this complication.


We preferred avoiding ASLA.
[KT] The text today does not avoid ASLA and in fact requires the use of ASLA 
(quite correctly) for FlexAlgo application. Peter has confirmed the same. I am 
simply asking to avoid the complications of using Generic Metric in both ASLA 
and outside it. Whatever new "application" we invent to use this generic metric 
type, can use ASLA so that the Generic Metric can be very cleanly shared 
between applications. The encoding allows for using the same value - sharing 
single advertisement across applications or doing a different one 
per-application.
 Generic metric is allowed in ASLA, it is also allowed in all 
traditional TLVs/LSAs where link attributes are advertised.
This is required so that all the applications, existing and new can make use of 
generic metric.



Juniper Business Use Only
From: Ketan Talaulikar (ketant) mailto:ket...@cisco.com>>
Sent: Wednesday, May 26, 2021 12:09 PM
To: Tony Li mailto:tony...@tony.li>>
Cc: Acee Lindem (acee) 
mailto:acee=40cisco@dmarc.ietf.org>>; 
lsr@ietf.org<mailto:lsr@ietf.org>; 
draft-hegde-lsr-flex-algo-bw-...@ietf.org<mailto:draft-hegde-lsr-flex-algo-bw-...@ietf.org>
Subject: RE: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, 
Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

[External Email. Be cautious of content]

Hi Tony,

Please check inline below.

From: Tony Li mailto:tony1ath...@gmail.com>> On Behalf 
Of Tony Li
Sent: 25 May 2021 00:15
To: Ketan Talaulikar (ketant) mailto:ket...@cisco.com>>
Cc: Acee Lindem (acee) 
mailto:acee=40cisco@dmarc.ietf.org>>; 
lsr@ietf.org<mailto:lsr@ietf.org>; 
draft-hegde-lsr-flex-algo-bw-...@ietf.org<mailto:draft-hegde-lsr-flex-algo-bw-...@ietf.org>
Subject: Re: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, 
Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02


Hi Ketan,

In general, I support the adoption of this document. There is, however, one 
specific point which is not clear to me (8) below that I would appreciate some 
clarity on before adoption.


As the chairs have noted, adoption is binary and not contingent upon rough 
consensus on the content, just on rough consensus on the interest.
[KT] I believe the WG has (or must have) the ability to determine portions of 
the proposal to adopt and/or to split documents. I have seen this in recent 
past in other WGs. In any case, it is not a point that I wish to argue or 
debate on - especially in the context of this document. My point (8) was 
clarified and hence I fall in the binary YES in this instance.


  1.  Why is the Generic Metric type in ISIS limited to 3 byte size? OSPF 
allows 4 byte size and so why not the same for ISIS? Elsewhere in the document, 
I do see MAX METRIC being referred to as 4,261,412,864.


Because I'm a lazy sod.

It's far easier to detect metric overflow on three byte values than four byte 
values. True, four byte is not impossible, but it's just quick and easy with 
three byte values.  Adding a fourth byte would add range to the metric space, 
but in practice, this seemed like it was not really relevant. Most areas are 
not a very high diameter and the need for detailed metric distinctions has not 
been that high.  Thus, we went with a 3 byte metric in RFC 5305 (sec 3.7) and 
that seems to work.
[KT] The Generic Metric is by definition something that will get extended in 
the future and we don't know what use-cases might arise. It doesn't seem right 
to follow in the steps of an administratively assigned metric type like the TE 
metric. Therefore, I suggest to make it variable.

[KT] Regarding metric overflow, I think it would be better to leave it to 
implem

Re: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

[Ketan Talaulikar (ketant)]

Hi Shraddha,

Please check inline below with KT2

From: Lsr  On Behalf Of Shraddha Hegde
Sent: 27 May 2021 18:31
To: Tony Li ; Ketan Talaulikar (ketant) 
Cc: lsr@ietf.org; draft-hegde-lsr-flex-algo-bw-...@ietf.org; Acee Lindem (acee) 

Subject: Re: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, 
Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02


Snipped..


5.
For the Max B/w Link attribute and its comparison with the FAD b/w constraints, 
I see the reference to ASLA. While in OSPF max-bandwidth is not allowed in ASLA 
- 
https://datatracker.ietf.org/doc/html/rfc8920#section-7<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc8920*section-7__;Iw!!NEt6yMaO-gk!RnUnB56xWLSsNhl6V89tximFfO34nZ_CSZD-HtoxBg6g9qBJ8rOO1artxJfyA-14$>,
 in case of ISIS also, it is not really appropriate for use within ASLA 
-https://datatracker.ietf.org/doc/html/rfc8919#section-4.2.1<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc8919*section-4.2.1__;Iw!!NEt6yMaO-gk!RnUnB56xWLSsNhl6V89tximFfO34nZ_CSZD-HtoxBg6g9qBJ8rOO1artxHHnJfE7$>?


I'm sorry, I don't understand this comment.
[KT] In 
https://datatracker.ietf.org/doc/html/draft-hegde-lsr-flex-algo-bw-con-02#section-3.2.1<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-hegde-lsr-flex-algo-bw-con-02*section-3.2.1__;Iw!!NEt6yMaO-gk!RnUnB56xWLSsNhl6V89tximFfO34nZ_CSZD-HtoxBg6g9qBJ8rOO1artxAEMtKzf$>


The Maximum Link Bandwidth as advertised by the sub-sub-

   TLV 23 of ASLA [RFC 
8920<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc8920__;!!NEt6yMaO-gk!RnUnB56xWLSsNhl6V89tximFfO34nZ_CSZD-HtoxBg6g9qBJ8rOO1artxMntRW1t$>]
 MUST be compared against the Minimum

   bandwidth advertised in FAEMB sub-TLV.

And in the 
https://datatracker.ietf.org/doc/html/rfc8920#section-7<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc8920*section-7__;Iw!!NEt6yMaO-gk!RnUnB56xWLSsNhl6V89tximFfO34nZ_CSZD-HtoxBg6g9qBJ8rOO1artxJfyA-14$>


Maximum link bandwidth is an application-independent attribute of the

   link that is defined in 
[RFC3630<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc3630__;!!NEt6yMaO-gk!RnUnB56xWLSsNhl6V89tximFfO34nZ_CSZD-HtoxBg6g9qBJ8rOO1artxMwurpJX$>].
  Because it is an application-

   independent attribute, it MUST NOT be advertised in the ASLA sub-TLV.

Somewhat similar for ISIS as well.


I'm sorry, I'm still not understanding your comment. Are you objecting because 
we are expecting TLV 23 in ASLA?  I believe that FlexAlgo has already requested 
this, updating the other two protocols.


 As per RFC 8920, Maximum Link Bandwidth cannot be advertised in 
ASLA. Will update the text to reflect Maximum Link Bandwidth sub-TLV in 
Extended Link TLV of Extended Link opaque LSA.
[KT2] Thanks.

For ISIS, Maximum Link Bandwidth sub-TLV is allowed in ASLA just that different 
values for different applications is not allowed. Maximum Link bandwidth is 
also allowed with all bits set to zero in SABM/UDABM  or each individual 
application bit set for all applications making use of ASLA.
[KT2] Yes, you are correct. The RFC8919 does not mandate or require Max Link 
Bandwidth to be signaled within ASLA (at least that was my reading). If so, 
perhaps it is better to not require that in this document - just keep in the 
base. Would that not work? And if it were advertised in the ASLA (as RFC8919 
allows it), then perhaps a reference to the RFC8919 will be important on how it 
is to be done - basically exactly what you described above.

Thanks,
Ketan

RFC 8919 sec 4.2.1
"  Maximum link bandwidth is an application-independent attribute of the
   link.  When advertised using the Application-Specific Link Attributes
   sub-TLV, multiple values for the same link MUST NOT be advertised.
   This can be accomplished most efficiently by having a single
   advertisement for a given link where the Application Identifier Bit
   Mask identifies all the applications that are making use of the value
   for that link."


  1.  Document should cover the FAPM aspects for the Generic Metric and 
especially the Bandwidth metric.
 As long as we have fixed length generic metric, there won't be any 
changes to FAPM. We'll add a section to clarify about FAPM



Juniper Business Use Only
From: Tony Li mailto:tony1ath...@gmail.com>> On Behalf 
Of Tony Li
Sent: Wednesday, May 26, 2021 10:10 PM
To: Ketan Jivan Talaulikar mailto:ket...@cisco.com>>
Cc: Acee Lindem (acee) 
mailto:acee=40cisco@dmarc.ietf.org>>; 
lsr@ietf.org<mailto:lsr@ietf.org>; 
draft-hegde-lsr-flex-algo-bw-...@ietf.org<mailto:draft-hegde-lsr-flex-algo-bw-...@ietf.org>
Subject: Re: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, 
Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

[External Email. Be cautious of content]


Hi Ketan,


  1.  Why is the Generic Metri

Re: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

[Ketan Talaulikar (ketant)]

Perhaps, I should have been more careful with the word "variable". Initially, I 
meant allowing either 24 or 32 bits size (to me making it 32 just covers both 
the bases). But then the discussions on delay brought to my mind that perhaps 
even 64-bit metric might be useful. So the variable in my mind was either 32 or 
64.

And I agree that there is no impact on FAPM if we picked the Generic Metric of 
32-bit (or even kept it 24-bit). And yes, thanks Shraddha for agreeing to cover 
the applicability and aspects of FAPM in this document. Similar also applies 
for the OSPF FAAM, btw.

Thanks,
Ketan

-Original Message-
From: Peter Psenak  
Sent: 27 May 2021 18:20
To: Shraddha Hegde ; Tony Li ; Ketan 
Talaulikar (ketant) 
Cc: lsr@ietf.org; draft-hegde-lsr-flex-algo-bw-...@ietf.org; Acee Lindem (acee) 

Subject: Re: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, 
Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

On 27/05/2021 14:36, Shraddha Hegde wrote:
>> we only need the new TLV to carry FAPM if we make the Generic Metric's size 
>> variable. If we keep it fixed size, we >should be fine with the existing 
>> FAPM.
> 
> Yes agree.
> The idea of making generic metric variable length is worth considering.
> I don't see a strong enough usecase right now to make it variable 
> length but will wait

nor do I.

thanks,
Peter



> for inputs from WG.
> 
> Rgds
> Shraddha
> 
> 
> Juniper Business Use Only
> 
> -Original Message-
> From: Peter Psenak 
> Sent: Wednesday, May 26, 2021 10:27 PM
> To: Tony Li ; Ketan Jivan Talaulikar 
> 
> Cc: lsr@ietf.org; draft-hegde-lsr-flex-algo-bw-...@ietf.org; Acee 
> Lindem (acee) 
> Subject: Re: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: 
> Bandwidth, Delay, Metrics and Constraints" - 
> draft-hegde-lsr-flex-algo-bw-con-02
> 
> [External Email. Be cautious of content]
> 
> 
> Hi Tony, Ketan,
> 
> On 26/05/2021 18:40, Tony Li wrote:
> 
>>> */[KT] Generic Metric is used for the links. When we get to the 
>>> computation of inter-area or external routes, we will need to get 
>>> into FAPM. The draft at a minimum should discuss the applicability 
>>> of the Generic Metric and its use as FAPM. Now, if we do make the 
>>> Generic Metric size variable (as suggested above), then we will 
>>> likely need a new TLV for a variable size FAPM equivalent?/*
>>
>>
>> We would need a new TLV regardless of the metric size as the FAPM TLV 
>> only carries the default metric. We are not proposing that TLV at 
>> this time. That’s future work.
> 
> we only need the new TLV to carry FAPM if we make the Generic Metric's size 
> variable. If we keep it fixed size, we should be fine with the existing FAPM.
> 
> 
> thanks,
> Peter
>>
>> Tony
>>
> 
> 

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

Re: [Lsr] LSR WG Adoption Call for "Algorithm Related IGP-Adjacency SID Advertisement"

[Ketan Talaulikar (ketant)]

Hello All,

I am not aware of any IPR associated with this document.

Thanks,
Ketan

-Original Message-
From: Lsr  On Behalf Of Christian Hopps
Sent: 27 May 2021 02:27
To: lsr@ietf.org
Cc: cho...@chopps.org
Subject: [Lsr] LSR WG Adoption Call for "Algorithm Related IGP-Adjacency SID 
Advertisement"


Hi Folks,

This begins a 2 week WG Adoption Call for the following draft:

https://datatracker.ietf.org/doc/draft-peng-lsr-algorithm-related-adjacency-sid/

Please indicate your support or objections by June 9th, 2021

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

Thanks,
Acee and Chris.

___
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] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

[Ketan Talaulikar (ketant)]

Hi Tony,

Please check inline below.

From: Tony Li  On Behalf Of Tony Li
Sent: 25 May 2021 00:15
To: Ketan Talaulikar (ketant) 
Cc: Acee Lindem (acee) ; lsr@ietf.org; 
draft-hegde-lsr-flex-algo-bw-...@ietf.org
Subject: Re: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, 
Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02


Hi Ketan,

In general, I support the adoption of this document. There is, however, one 
specific point which is not clear to me (8) below that I would appreciate some 
clarity on before adoption.


As the chairs have noted, adoption is binary and not contingent upon rough 
consensus on the content, just on rough consensus on the interest.
[KT] I believe the WG has (or must have) the ability to determine portions of 
the proposal to adopt and/or to split documents. I have seen this in recent 
past in other WGs. In any case, it is not a point that I wish to argue or 
debate on – especially in the context of this document. My point (8) was 
clarified and hence I fall in the binary YES in this instance.



  1.  Why is the Generic Metric type in ISIS limited to 3 byte size? OSPF 
allows 4 byte size and so why not the same for ISIS? Elsewhere in the document, 
I do see MAX METRIC being referred to as 4,261,412,864.


Because I’m a lazy sod.

It’s far easier to detect metric overflow on three byte values than four byte 
values. True, four byte is not impossible, but it’s just quick and easy with 
three byte values.  Adding a fourth byte would add range to the metric space, 
but in practice, this seemed like it was not really relevant. Most areas are 
not a very high diameter and the need for detailed metric distinctions has not 
been that high.  Thus, we went with a 3 byte metric in RFC 5305 (sec 3.7) and 
that seems to work.
[KT] The Generic Metric is by definition something that will get extended in 
the future and we don’t know what use-cases might arise. It doesn’t seem right 
to follow in the steps of an administratively assigned metric type like the TE 
metric. Therefore, I suggest to make it variable.


[KT] Regarding metric overflow, I think it would be better to leave it to 
implementations on how to deal with it. A guidance similar to below (from 
draft-ietf-lsr-flex-algo) would help handle the condition in a manner that does 
not cause interop issues. Theoretically, it is something that is independent of 
the size of the metric.

   During the route computation, it is possible for the Flex-Algorithm
   specific metric to exceed the maximum value that can be stored in an
   unsigned 32-bit variable.  In such scenarios, the value MUST be
   considered to be of value 4,294,967,295 during the computation and
   advertised as such.


  1.
  2.  Would be good to cover the max-metric considerations for the Generic 
Metric. Similar to 
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-flex-algo-15#section-15.3


Fair




  1.
  2.  Since the draft is covering FlexAlgo, I would have expected that Generic 
Metric is carried only in the ASLA and this document specifies usage only for 
the FA application. Later this can be also used/extended for other applications 
but still within ASLA. Keeping an option of advertising both outside and within 
the ASLA is problematic – we will need precedence rules and such. I prefer we 
avoid this complication.


We preferred avoiding ASLA.
[KT] The text today does not avoid ASLA and in fact requires the use of ASLA 
(quite correctly) for FlexAlgo application. Peter has confirmed the same. I am 
simply asking to avoid the complications of using Generic Metric in both ASLA 
and outside it. Whatever new “application” we invent to use this generic metric 
type, can use ASLA so that the Generic Metric can be very cleanly shared 
between applications. The encoding allows for using the same value – sharing 
single advertisement across applications or doing a different one 
per-application.


  1.
  2.  For the newly proposed FAD b/w constraints, I would suggest the following 
names for the constraint sub-TLVs where the b/w value signalled by all is 
compared with the Max Link B/w attribute. This is just to make the meaning, at 
least IMHO, more clear.

 *   Exclude Higher Bandwidth Links
 *   Exclude Lower Bandwidth Links
 *   Include-Only Higher Bandwidth Links
 *   Include-Only Lower Bandwidth Links

  1.  Similar naming for the FAD delay constraints as well would help. Though I 
can only think of the use of “exclude” for links above a certain delay 
threshold to be more practical but perhaps others might eventually be required 
as well?


Thank you for the suggestions.




  1.
  2.  For the Max B/w Link attribute and its comparison with the FAD b/w 
constraints, I see the reference to ASLA. While in OSPF max-bandwidth is not 
allowed in ASLA - https://datatracker.ietf.org/doc/html/rfc8920#section-7, in 
case of ISIS also, it is not really appropriate for use within ASLA 
-https://datatracker.ie

Re: [Lsr] WG adoption call for draft-acee-lsr-ospf-transport-instance-02

[Ketan Talaulikar (ketant)]

Hello Authors,

Some post adoption comments/feedback on the draft :

1) RFC6823 for ISIS GenApp allows that top-level TLV to be also advertised in 
the "default instance". Each application is able to specify whether this is 
allowed or not for itself. Any plans to follow the same approach in OSPF?

2) The application specific information may not only be associated with the 
node. We also need the ability to advertise the application specific info 
associated with the link and prefix as well. There was some feedback on this 
point during the adoption call as well with which I concur. How would this be 
addressed? Via Transport Link and Prefix LSAs? Or is each application expect to 
be bring in the link and prefix descriptors under the application TLV in the 
proposed LSA? IMHO, it would be valuable to preserve the granularity of 
advertisement offered by OSPF via LSAs for this use-case as well.

Thanks,
Ketan

-Original Message-
From: Lsr  On Behalf Of Christian Hopps
Sent: 21 May 2021 20:35
To: Christian Hopps 
Cc: lsr@ietf.org; lsr-...@ietf.org; 
draft-acee-lsr-ospf-transport-insta...@ietf.org
Subject: Re: [Lsr] WG adoption call for 
draft-acee-lsr-ospf-transport-instance-02


The work is adopted, authors please resubmit as:

draft-ietf-lsr-ospf-transport-instance-00

Thanks,
Chris.

Christian Hopps  writes:

> This begins a 2 week WG adoption call for the following draft:
>
>https://datatracker.ietf.org/doc/draft-acee-lsr-ospf-transport-instance/
>
> Please indicate your support or objection by May 16th, 2021.
>
> Authors, please respond to the list indicating whether you are aware of any 
> IPR that applies to this draft.
>
> Historical Note: The original OSPF transport instance document was adopted by 
> the OSPF WG back in 2009, it was last updated in 2014, and then revived as an 
> individual submission to LSR in Sep 2020. :)
>
> Thanks,
> Chris.
>
> ___
> 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] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

[Ketan Talaulikar (ketant)]

Hello Authors/All,

In general, I support the adoption of this document. There is, however, one 
specific point which is not clear to me (8) below that I would appreciate some 
clarity on before adoption.

Some questions/comments/suggestions:


  1.  Why is the Generic Metric type in ISIS limited to 3 byte size? OSPF 
allows 4 byte size and so why not the same for ISIS? Elsewhere in the document, 
I do see MAX METRIC being referred to as 4,261,412,864.
  2.  Would be good to cover the max-metric considerations for the Generic 
Metric. Similar to 
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-flex-algo-15#section-15.3
  3.  Since the draft is covering FlexAlgo, I would have expected that Generic 
Metric is carried only in the ASLA and this document specifies usage only for 
the FA application. Later this can be also used/extended for other applications 
but still within ASLA. Keeping an option of advertising both outside and within 
the ASLA is problematic – we will need precedence rules and such. I prefer we 
avoid this complication.
  4.  For the newly proposed FAD b/w constraints, I would suggest the following 
names for the constraint sub-TLVs where the b/w value signalled by all is 
compared with the Max Link B/w attribute. This is just to make the meaning, at 
least IMHO, more clear.
 *   Exclude Higher Bandwidth Links
 *   Exclude Lower Bandwidth Links
 *   Include-Only Higher Bandwidth Links
 *   Include-Only Lower Bandwidth Links
  5.  Similar naming for the FAD delay constraints as well would help. Though I 
can only think of the use of “exclude” for links above a certain delay 
threshold to be more practical but perhaps others might eventually be required 
as well?
  6.  For the Max B/w Link attribute and its comparison with the FAD b/w 
constraints, I see the reference to ASLA. While in OSPF max-bandwidth is not 
allowed in ASLA - https://datatracker.ietf.org/doc/html/rfc8920#section-7, in 
case of ISIS also, it is not really appropriate for use within ASLA - 
https://datatracker.ietf.org/doc/html/rfc8919#section-4.2.1?
  7.  Document should cover the FAPM aspects for the Generic Metric and 
especially the Bandwidth metric.
  8.  The document introduces a new Generic Metric type called Bandwidth 
metric. I’ve been trying to follow some of the discussion related to this on 
the mailing list – about it being cumulative or not. I am perhaps somewhat 
confused by those discussions. The OSPF/ISIS SPT computation has always worked 
with cumulative link (and prefix) metrics. If the computation for the Generic 
Metric of this new type b/w is not going to be cumulative (I thought it is – 
but not very clear anymore), then the document needs to describe the 
computation algorithm. Is it then hop count based? Perhaps I am missing 
something very basic here and if so, please point me to the text in the draft.

Thanks,
Ketan

From: Lsr  On Behalf Of Acee Lindem (acee)
Sent: 13 May 2021 02:39
To: lsr@ietf.org
Cc: draft-hegde-lsr-flex-algo-bw-...@ietf.org
Subject: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, 
Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

Esteemed Members of the LSR WG,

This begins a 2 week WG adoption call for the following draft:

 https://datatracker.ietf.org/doc/draft-hegde-lsr-flex-algo-bw-con/

Please indicate your support or objection by May 27th, 2021.

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

Thanks,
Chris and Acee


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

Re: [Lsr] [Technical Errata Reported] RFC5185 (6506)

[Ketan Talaulikar (ketant)]

Hi John/Acee/Peter,

I was not in a position to judge for myself on this matter and hence thought 
prudent to first raise this as an erratum.

I have no issues with pursuing this update via a bis.

Thanks,
Ketan

-Original Message-
From: Peter Psenak  
Sent: 12 May 2021 12:59
To: John Scudder ; Ketan Talaulikar (ketant) 
; lsr@ietf.org
Cc: s...@nuovasystems.com; aos...@redback.com; Alvaro Retana 
; Martin Vigoureux ; 
a...@cisco.com; Acee Lindem (acee) 
Subject: Re: [Technical Errata Reported] RFC5185 (6506)

Hi Jonh,

On 10/05/2021 20:34, John Scudder wrote:
> Hi All,
> 
> I took a look at the list thread Ketan references at the bottom of the 
> proposed erratum. It seems pretty clear this would be a technical change vs. 
> the WG consensus when the document was progressed, and should be rejected 
> (see https://www.ietf.org/about/groups/iesg/statements/processing-rfc-errata/ 
> #7). The appropriate way to pursue this looks to be an update or bis.
> 
> If there’s any disagreement, please let me know (and let me know why you 
> think it’s appropriate as an erratum).

no disagreement on my side.

thanks,
Peter


> 
> Thanks,
> 
> —John
> 
>> On Apr 2, 2021, at 8:29 AM, RFC Errata System  
>> wrote:
>>
>> [External Email. Be cautious of content]
>>
>>
>> The following errata report has been submitted for RFC5185, "OSPF 
>> Multi-Area Adjacency".
>>
>> --
>> You may review the report below and at:
>> https://urldefense.com/v3/__https://www.rfc-editor.org/errata/eid6506
>> __;!!NEt6yMaO-gk!WPFiufTtTdnWpOVBJkxDMATvZslLDxV_ss4NJ_eazUR-7R1mCBVt
>> Z5hadu8NhQ$
>>
>> --
>> Type: Technical
>> Reported by: Ketan Talaulikar 
>>
>> Section: 2.7
>>
>> Original Text
>> -
>>Multi-area adjacencies are announced as point-to-point links.  Once
>>the router's multi-area adjacency reaches the FULL state, it will be
>>added as a link type 1 to the Router Link State Advertisement (LSA)
>>with:
>>
>>   Link ID = Remote's Router ID
>>
>>   Link Data = Neighbor's IP Address or IfIndex (if the underlying
>>   interface is unnumbered).
>>
>>Unlike numbered point-to-point links, no type 3 link is advertised
>>for multi-area adjacencies.
>>
>>
>> Corrected Text
>> --
>>Multi-area adjacencies are announced as point-to-point links.  Once
>>the router's multi-area adjacency reaches the FULL state, it will be
>>added as a link type 1 to the Router Link State Advertisement (LSA)
>>with:
>>
>>   Link ID = Remote's Router ID
>>
>>   Link Data = Router interface's IP Address or IfIndex (if the underlying
>>   interface is unnumbered).
>>
>>Unlike numbered point-to-point links, no type 3 link is advertised
>>for multi-area adjacencies.
>>
>>
>> Notes
>> -
>> The encoding of Link Data as specified in RFC5185 is not consistent with the 
>> base OSPF specification in RFC2328. This has resulted in different behaviors 
>> in deployed implementations where some follow RFC2328 (i.e. the corrected 
>> text) while others follow the Original text of RFC5185 leading to interop 
>> issues.
>>
>> More importantly, for implementations of RFC5185, it is not possible to 
>> determine the Neighbor's interface IfIndex unless some additional mechanisms 
>> (that have not been specified or referenced by RFC5185) are implemented - 
>> viz. RFC8510.
>>
>> This topic has been discussed in the LSR WG recently and this errata 
>> is being raised to track this issue : 
>> https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/lsr
>> /iL85WkrqhI17wUrxd-WozMQvKtE/__;!!NEt6yMaO-gk!WPFiufTtTdnWpOVBJkxDMAT
>> vZslLDxV_ss4NJ_eazUR-7R1mCBVtZ5hYBp-ZDA$
>>
>> Instructions:
>> -
>> This erratum is currently posted as "Reported". If necessary, please 
>> use "Reply All" to discuss whether it should be verified or rejected. 
>> When a decision is reached, the verifying party can log in to change 
>> the status and edit the report, if necessary.
>>
>> --
>> RFC5185 (draft-ietf-ospf-multi-area-adj-09)
>> --
>> Title   : OSPF Multi-Area Adjacency
>> Publication Date: May 2008
>> Author(s)   : S. Mirtorabi, P. Psenak, A. Lindem, Ed., A. Oswal
>> Category: PROPOSED STANDARD
>> Source  : Open Shortest Path First IGP
>> Area: Routing
>> Stream  : IETF
>> Verifying Party : IESG
> 
> 
> 

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

Re: [Lsr] Last Call: (IS-IS Extension to Support Segment Routing over IPv6 Dataplane) to Proposed Standard

[Ketan Talaulikar (ketant)]

Hi Peter,

I agree that the support for the Prefix Attribute Flags TLV is required in the 
Locator TLV.

Thanks,
Ketan

From: Lsr  On Behalf Of Alvaro Retana
Sent: 07 May 2021 19:23
To: Peter Psenak (ppsenak) ; lsr@ietf.org
Cc: cho...@chopps.org; draft-ietf-lsr-isis-srv6-extensi...@ietf.org; Van De 
Velde, Gunter (Nokia - BE/Antwerp) 
Subject: Re: [Lsr] Last Call:  
(IS-IS Extension to Support Segment Routing over IPv6 Dataplane) to Proposed 
Standard

On May 3, 2021 at 5:17:58 AM, Peter Psenak wrote:

> Technically I agree with you and if everybody agrees, I'm fine to
> enforce the presence of the Prefix Attribute Flags TLV in the Locator TLV.

So...what does everyone else think?

We need to close on this point before the IESG evaluates the document.  I'm 
requesting it to be put on the May/20 telechat, which means that we should have 
a resolution and updated draft by the end of next week.


Thanks!

Alvaro.



On May 3, 2021 at 5:17:58 AM, Peter Psenak 
(ppse...@cisco.com) wrote:
Hi Gunter,

Prefix Attribute Flags Sub-TLV has been defined as an optional Sub-TLV.
The problem you describe is not specific to Locator TLV, same applies to
regular IPv4/v6 prefixes (forget SR MPLS for a while) - if the Prefix
Attribute Flags TLV is not included, one can not tell whether the prefix
has been propagated (L1->L2) or generated as a result of the local
interface attached on the originator. Same applies to redistribution and
R-flag for IPv4 prefix TLVs.

SRv6 Locator TLV has been defined a while back and the Prefix Attribute
Flags Sub-TLV has always been an optional Sub-TLV of it. I'm not sure we
can start to mandate the Prefix Attribute Flags TLV at this point.

Technically I agree with you and if everybody agrees, I'm fine to
enforce the presence of the Prefix Attribute Flags TLV in the Locator TLV.

thanks,
Peter


On 03/05/2021 10:45, Van De Velde, Gunter (Nokia - BE/Antwerp) wrote:
> Hi Peter, All,
>
> Could we update to "draft-ietf-lsr-isis-srv6-extensions" that the 
> prefix-attribute tlv is mandatory when a locator is redistributed?
>
> Why?
> *When calculating a LFA for an SRv6 End.SID we better know if the locator has 
> been redistributed or not for a correct operation.
>
> Reasoning:
> * A locator has the D bit. This one is set when we redistribute from L2 to L1.
> ** So this end-sid will not be used as we know that it is redistributed.
>
> * In the other direction (L1-L2), we only know that a locator is 
> redistributed from L1 to L2 if the prefix-attribute sub-tlv is advertised.
> ** This means if the operator does not configure advertisement of the 
> prefix-attribute tlv, ISIS could potentially use an end-sid which does not 
> terminate on the expected node.
>
> * Compared to sr-mpls, a prefix-sid has the R flag indicating it is 
> redistributed.
> * We don't have that for locator end-sids.
>
> Relevant snip from " draft-ietf-lsr-isis-srv6-extensions"
>
> 7.1. SRv6 Locator TLV Format
>
> The SRv6 Locator TLV has the following format:
>
> 0 1 2 3
> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | Type | Length |R|R|R|R| MT ID |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> Type: 27
>
> Length: variable.
>
> R bits: reserved for future use. They MUST be
> set to zero on transmission and MUST be ignored on receipt.
>
> MT ID: Multitopology Identifier as defined in [RFC5120].
> Note that the value 0 is legal.
>
> Followed by one or more locator entries of the form:
>
> 0 1 2 3
> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | Metric |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | Flags | Algorithm |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | Loc Size | Locator (variable)...
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | Sub-TLV-len | Sub-TLVs (variable) . . . |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>
> Metric: 4 octets. As described in [RFC5305].
>
> Flags: 1 octet. The following flags are defined
>
> 0
> 0 1 2 3 4 5 6 7
> +-+-+-+-+-+-+-+-+
> |D| Reserved |
> +-+-+-+-+-+-+-+-+
>
> where:
> D-flag: Same as described in section 4.1. of [RFC5305].
>
>
> G/
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] some doubt about RFC5329 ( Traffic Engineering Extensions to OSPF Version 3)

[Ketan Talaulikar (ketant)]

Hello,

Please check inline below.

From: Lsr  On Behalf Of Zengmin (A)
Sent: 20 April 2021 07:41
To: lsr@ietf.org
Cc: Gaoqiangzhou 
Subject: [Lsr] some doubt about RFC5329 ( Traffic Engineering Extensions to 
OSPF Version 3)



Hi ALL,

In RFC5329, OSPFv3 TE Link TLV have below sub-TLVs
18 - Neighbor ID (8 octets) ： Neighbor Interface ID ， Neighbor Router ID
19 - Local Interface IPv6 Address
20 - Remote Interface IPv6 Address

question1：
4.4. Remote Interface IPv6 Address Sub-TLV
if link-LSA not have a prefix length of 128 and the LA-bit
how to get remote Interface ipv6 address to fill the tlv value.
[KT] I believe the LA-bit is required, the prefix length of 128 is not a 
must-have. If the remote address cannot be determined then there is no issue - 
it is possible that links have only link-local addresses.

question2：
if router only advertise :
18 - Neighbor ID (8 octets) ： Neighbor Interface ID ， Neighbor Router ID
19 - Local Interface IPv6 Address
how to match router's TE Link TLV with peer router's TE Link TLV
[KT] Matching is done using the interface-IDs in OSPFv3. This is something that 
is always there and available unlike IPv6 local/remote addresses which are 
optional (e.g. when links have link-local addressing only).

question3：
4. Link TLV --- " The Neighbor ID sub-TLV is mandatory for OSPFv3 Traffic 
Engineering support. "
it means Local Interface IPv6 Address Sub-TLV is not mandatory
if only advertise : 18 - Neighbor ID (8 octets)
how to match router's TE Link TLV with peer router's TE Link TLV
[KT] Please see previous comment. The local & remote interface IDs are 
available in the base OSPFv3 Router-LSA description of the link and are 
therefore fundamental for link correlation in OSPFv3.

Thanks,
Ketan


Thanks,
Jenny


In section 4 Link TLV：
[cid:image001.png@01D7361C.1589B710]

[cid:image002.png@01D7361C.1589B710]

[cid:image003.png@01D7361C.1589B710]


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

Re: [Lsr] [IANA #1195545] Early IANA Allocation Request for "OSPF Reverse Metric" - draft-ietf-lsr-ospf-reverse-metric-02

[Ketan Talaulikar (ketant)]

Thanks Acee, John and Amanda.

-Original Message-
From: Amanda Baber via RT  
Sent: 20 April 2021 04:52
To: Acee Lindem (acee) ; j...@juniper.net
Cc: lsr@ietf.org; draft-ietf-lsr-ospf-reverse-met...@ietf.org
Subject: [IANA #1195545] Early IANA Allocation Request for "OSPF Reverse 
Metric" - draft-ietf-lsr-ospf-reverse-metric-02

Hi,

We've made the following RFC 7120 early allocations in the Link Local 
Signalling TLV Identifiers (LLS Types) registry:

19  Reverse Metric TLV (TEMPORARY - registered 2021-04-19, expires 
2022-04-19)  [draft-ietf-lsr-ospf-reverse-metric-02]

20  Reverse TE Metric TLV (TEMPORARY - registered 2021-04-19, expires 
2022-04-19)   [draft-ietf-lsr-ospf-reverse-metric-02]

Please see
https://www.iana.org/assignments/ospf-lls-tlvs

If the document hasn't been approved for publication by March, we'll contact 
you then about renewing.

Best regards,

Amanda Baber
Lead IANA Services Specialist

On Mon Apr 19 16:28:59 2021, j...@juniper.net wrote:
> OK, thanks. Approved.
> 
> —John
> 
> On Apr 19, 2021, at 9:55 AM, Acee Lindem (acee) 
> mailto:a...@cisco.com>> wrote:
> 
> 
> 
> Hi John,
> 
> From: John Scudder mailto:j...@juniper.net>>
> Date: Monday, April 19, 2021 at 9:52 AM
> To: Acee Lindem mailto:a...@cisco.com>>
> Cc: IANA mailto:i...@iana.org>>,
> "lsr@ietf.org"
> mailto:lsr@ietf.org>>, "draft-ietf-lsr-ospf-reverse- 
> met...@ietf.org"
> mailto:draft-ietf-lsr-
> ospf-reverse-met...@ietf.org>>
> Subject: Re: Early IANA Allocation Request for "OSPF Reverse Metric" -
> draft-ietf-lsr-ospf-reverse-metric-02
> 
> Hi Acee,
> 
> Have you determined that the requirements of RFC 7120 Section 2 are 
> met?
> 
> Yes – we hope to WG last call this draft as WG bandwidth permits.  The 
> same functionality has been implemented in IS-IS for some time.
> 
> Thanks,
> Acee
> 
> Thanks,
> 
> —John
> 
> P. S. As an aside, that’s a huuuge private use range in that registry.
> Any idea if it’s being made use of? Hard to imagine.
> 
> 
> On Apr 19, 2021, at 9:46 AM, Acee Lindem (acee) 
> mailto:a...@cisco.com>> wrote:
> Hi John,
> 
> The authors have requested early IANA allocation for the subject draft 
> to facilitate implementation. The suggested values are:
> 
> This specification updates Link Local Signaling TLV Identifiers
> registry:
> 
> https://www.iana.org/assignments/ospf-lls-tlvs/ospf-lls-
> tlvs.xhtml#ospf-lls-tlvs-1
> 
> The following values are requested for allocation:
> 
> o TBD (Suggested value 19) - Reverse Metric TLV
> 
> o TBD (Suggested value 20) - Reverse TE Metric TLV
> 
> Thanks,
> Acee
> 

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

Re: [Lsr] [IANA #1195548] IANA Early Allocation for "Advertising L2 Bundle Member Link Attributes in OSPF" - draft-ietf-lsr-ospf-l2bundles-00

[Ketan Talaulikar (ketant)]

Thanks Acee, John and Amanda.

-Original Message-
From: Amanda Baber via RT  
Sent: 20 April 2021 04:55
To: Acee Lindem (acee) 
Cc: lsr@ietf.org; j...@juniper.net; draft-ietf-lsr-ospf-l2bund...@ietf.org
Subject: [IANA #1195548] IANA Early Allocation for "Advertising L2 Bundle 
Member Link Attributes in OSPF" - draft-ietf-lsr-ospf-l2bundles-00

Hi,

We've made the following RFC 7120 early allocations:

In the OSPFv2 Extended Link TLV Sub-TLVs registry:

24  L2 Bundle Member Attributes (TEMPORARY - registered 2021-04-19, expires 
2022-04-19) [draft-ietf-lsr-ospf-l2bundles-00]

Please see
https://www.iana.org/assignments/ospfv2-parameters

In the OSPFv3 Extended-LSA Sub-TLVs registry:

29  L2 Bundle Member Attributes (TEMPORARY - registered 2021-04-19, expires 
2022-04-19) [draft-ietf-lsr-ospf-l2bundles-00]

Please see
https://www.iana.org/assignments/ospfv3-parameters

If the document hasn't been approved for publication by March, we'll contact 
you about renewing.

Best regards,

Amanda Baber
Lead IANA Services Specialist

On Mon Apr 19 21:05:14 2021, j...@juniper.net wrote:
> Yes, please do. Thanks.
> 
> —John
> 
> > On Apr 19, 2021, at 4:40 PM, Amanda Baber via RT  > pa...@iana.org> wrote:
> >
> >
> > Hi John,
> >
> > Can we move forward with this one?
> >
> > thanks,
> > Amanda
> >
> >> On Mon Apr 19 16:51:29 2021, a...@cisco.com wrote:
> >> This draft also meets the RFC 7120 section 2 requirements and is a 
> >> target for WG last call. The function has been implemented in IS-IS 
> >> (RFC 8668) and the OSPF functionality is analogous.
> >>
> >> Thanks,
> >> Acee
> >>
> >>
> >> From: Acee Lindem 
> >> Date: Monday, April 19, 2021 at 10:01 AM
> >> To: John Scudder , IANA 
> >> Cc: "lsr@ietf.org" , "draft-ietf-lsr-ospf- 
> >> l2bund...@ietf.org" 
> >> Subject: IANA Early Allocation for "Advertising L2 Bundle Member 
> >> Link Attributes in OSPF" - draft-ietf-lsr-ospf-l2bundles-00
> >>
> >> Hi John, IANA,
> >>
> >> The authors have requested early IANA allocation for the subject 
> >> draft to facilitate implementation.
> >>
> >> The following sub-TLV is added to the OSPFv2 Extended Link TLV sub- 
> >> TLVs registry under the OSPFv2 Parameters IANA registry:
> >>
> >> Value: Suggested Value - 24
> >>
> >> Name: L2 Bundle Member Attributes
> >>
> >> https://urldefense.com/v3/__https://www.iana.org/assignments/ospfv2
> >> -
> >> parameters/ospfv2-__;!!NEt6yMaO-
> >> gk!TzmXdQ9Zw6POSkjszruPsZCl2qNmoariZCfXO-TrK08S5N0QS39HeoVfCZjlhg$
> >> parameters.xhtml#extended-link-tlv-sub-tlvs
> >>
> >> The following sub-TLV is added to the OSPFv3 Extended LSA sub-TLVs 
> >> registry under the OSPFv3 Parameters IANA registry:
> >>
> >> Value: Suggested Value – 29
> >>
> >> Name: L2 Bundle Member Attributes
> >>
> >> https://urldefense.com/v3/__https://www.iana.org/assignments/ospfv3
> >> -
> >> parameters/ospfv3-__;!!NEt6yMaO-
> >> gk!TzmXdQ9Zw6POSkjszruPsZCl2qNmoariZCfXO-TrK08S5N0QS39HeoW9z27P9g$
> >> parameters.xhtml#extended-lsa-sub-tlvs
> >>
> >> Very similar function already exists for IS-IS as defined in RFC
> >> 8668
> >> -
> >> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/rfc866
> >> 8/__;!!NEt6yMaO- 
> >> gk!TzmXdQ9Zw6POSkjszruPsZCl2qNmoariZCfXO-TrK08S5N0QS39HeoUYAGpQQA$
> >>
> >> Thanks,
> >> Acee
> >>
> >>
> >>
> >>
> >

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

Re: [Lsr] John Scudder's No Objection on draft-ietf-lsr-ospf-prefix-originator-11: (with COMMENT)

[Ketan Talaulikar (ketant)]

Hello All,

We've posted the (final?) update for this draft to cover the minor changes as 
discussed with John (in the thread below) and with Ben (in a parallel thread).

https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospf-prefix-originator-12

Thanks once again for the reviews and inputs to improve this document.

Thanks,
Ketan (on behalf of co-authors)

-Original Message-
From: Ketan Talaulikar (ketant) 
Sent: 08 April 2021 11:05
To: 'Aijun Wang' ; 'John Scudder' 
; 'The IESG' 
Cc: lsr-cha...@ietf.org; aretana.i...@gmail.com; 
draft-ietf-lsr-ospf-prefix-origina...@ietf.org; cho...@chopps.org; lsr@ietf.org
Subject: RE: [Lsr] John Scudder's No Objection on 
draft-ietf-lsr-ospf-prefix-originator-11: (with COMMENT)

Hi John,

Using this latest thread to respond since it captures all the open comments.

Please check inline below and we'll update the draft once we reach a conclusion 
on this.


-Original Message-
From: Aijun Wang  
Sent: 08 April 2021 07:41
To: 'John Scudder' ; 'The IESG' 
Cc: lsr-cha...@ietf.org; aretana.i...@gmail.com; 
draft-ietf-lsr-ospf-prefix-origina...@ietf.org; cho...@chopps.org; lsr@ietf.org
Subject: RE: [Lsr] John Scudder's No Objection on 
draft-ietf-lsr-ospf-prefix-originator-11: (with COMMENT)

Hi, John:

-Original Message-
From: lsr-boun...@ietf.org  On Behalf Of John Scudder via 
Datatracker
Sent: Thursday, April 8, 2021 8:38 AM
To: The IESG 
Cc: lsr-cha...@ietf.org; aretana.i...@gmail.com; 
draft-ietf-lsr-ospf-prefix-origina...@ietf.org; cho...@chopps.org; lsr@ietf.org
Subject: [Lsr] John Scudder's No Objection on 
draft-ietf-lsr-ospf-prefix-originator-11: (with COMMENT)

John Scudder has entered the following ballot position for
draft-ietf-lsr-ospf-prefix-originator-11: No Objection

When responding, please keep the subject line intact and reply to all email 
addresses included in the To and CC lines. (Feel free to cut this introductory 
paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-prefix-originator/



--
COMMENT:
--

Thanks for the update to the document and the discussion. Many points are 
resolved, remaining discussion summarized below. And by the way, I wondered the 
same as Ben regarding "In the ECMP case is there a way to correlate (order of
appearance?) the listed router-IDs with the listed reachable addresses?"

1. I've cleared my discuss but as mentioned in earlier email, would still 
suggest an update to the abstract:

"I would prefer to see a sentence in the abstract as well, since for some 
people the abstract is the only look they’ll take at the document and for them, 
the question of “what is it for?” isn’t answered. I don’t insist on this, but I 
recommend it. The additional sentence, if you choose to add it, could be 
something like “this information does not change route computation but is 
expected to be useful for network analysis and troubleshooting”."
[KT] Ack - will update the abstract in the next version and add : " These 
extensions do not change the core OSPF route computation functionality but 
provide useful information for network analysis, troubleshooting and use-case 
like traffic engineering (especially on a controller or an application external 
to OSPF)."

2. Section 2.1:

   For intra-area prefix advertisements, the Prefix Source OSPF Router-
   ID Sub-TLV MUST be considered invalid and ignored if the OSPF Router
   ID field is not the same as Advertising Router field in the
   containing LSA.  Similar validation cannot be reliably performed for
   inter-area and external prefix advertisements.

As discussed with Ketan, I'm not sure if "ignored" is vague only to me, or if 
it might be to other readers of the spec. I leave it to the authors' discretion 
whether and how to elaborate.
[KT] "Ignore" is indeed really the basic option available in OSPF when 
receiving semantically invalid information within a TLV in an LSA. We cannot 
discard or change it and neither can we ignore/discard the entire LSA on this 
account. We normally recommend raising error logs, however in this case since 
OSPF itself is not processing the information, it seemed better to leave it to 
the actual user of the information.

4. Section 3:

   When an ABR generates inter-area prefix advertisements into its non-
   backbone areas corresponding to an inter-area prefix advertisement
   from the backbone area, the only way to determine the originating
   node information is based on the Prefix Source OSPF Router-ID and
   Prefix Source Router Address Sub-TLVs present in the inter-area
   prefix advertisement originated in

Re: [Lsr] Benjamin Kaduk's No Objection on draft-ietf-lsr-ospf-prefix-originator-10: (with COMMENT)

[Ketan Talaulikar (ketant)]

Hi Ben,

Thanks again for your review and comments. I will post the (final ?) update EOD 
Fri India time in case there are any other inputs.

Please check inline below.

-Original Message-
From: Benjamin Kaduk  
Sent: 09 April 2021 02:20
To: Ketan Talaulikar (ketant) 
Cc: The IESG ; lsr-cha...@ietf.org; aretana.i...@gmail.com; 
draft-ietf-lsr-ospf-prefix-origina...@ietf.org; cho...@chopps.org; lsr@ietf.org
Subject: Re: [Lsr] Benjamin Kaduk's No Objection on 
draft-ietf-lsr-ospf-prefix-originator-10: (with COMMENT)

Hi Ketan,

Thanks for the responses and updates; I just make a few notes inline.

On Wed, Apr 07, 2021 at 08:44:42AM +, Ketan Talaulikar (ketant) wrote:
> Hi Ben,
> 
> Thanks for your review.
> 
> An update to the draft with to address some of yours, John's and 
> Eric's comments has just been posted : 
> https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospf-prefix-origi
> nator-11
> 
> Please check inline below for responses.
> 
> -Original Message-
> From: Lsr  On Behalf Of Benjamin Kaduk via 
> Datatracker
> Sent: 07 April 2021 11:38
> To: The IESG 
> Cc: lsr-cha...@ietf.org; aretana.i...@gmail.com; 
> draft-ietf-lsr-ospf-prefix-origina...@ietf.org; cho...@chopps.org; 
> lsr@ietf.org
> Subject: [Lsr] Benjamin Kaduk's No Objection on 
> draft-ietf-lsr-ospf-prefix-originator-10: (with COMMENT)
> 
> Benjamin Kaduk has entered the following ballot position for
> draft-ietf-lsr-ospf-prefix-originator-10: No Objection
> 
> When responding, please keep the subject line intact and reply to all 
> email addresses included in the To and CC lines. (Feel free to cut 
> this introductory paragraph, however.)
> 
> 
> Please refer to 
> https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-prefix-originator
> /
> 
> 
> 
> --
> COMMENT:
> --
> 
> In the ECMP case is there a way to correlate (order of appearance?) the 
> listed router-IDs with the listed reachable addresses?
> [KT] No.
> 
> Are there cases where you might choose to only advertise one but not the 
> other of the prefix source Router-ID and address?
> [KT] Normally no. However, there is some text in Sec 5 about policies that 
> may be employed to abstract/hide information (e.g. across areas/ASes) - such 
> mechanisms may be used, as necessary, in a deployment.
> 
> Section 2.1
> 
>The parent TLV of a prefix advertisement MAY include more than one
>Prefix Source OSPF Router-ID sub-TLV, one corresponding to each of
>the Equal-Cost Multi-Path (ECMP) nodes that originated the given
>prefix.
> 
> Is there any subtlety (or complexity, I guess) to how the advertising node 
> knows about the other ECMP nodes advertising the same prefix?  
> [KT] An ABR performs the inter-area prefix advertisements based on its local 
> route computation (i.e. the sources contributing to its local intra-area 
> route). It is not affected by the advertisement of the same prefix by another 
> "peer/pair" ABR. I hope I've got your question right though.

I think you answerd a slightly different question than I intended (but it is 
still an interesting answer to hear).
In light of your explanation, I think my intended question degenerates into 
"are there any subtleties with how the node performs its local route 
computation", which probably gets an answer of "yes" but is clearly out of 
scope for this document.
[KT] You are correct.

> For example, would there be some transient discovery stage when first setting 
> up the ECMP advertisement and only a subset of the ECMP nodes are actually 
> listed in some advertisements that go out?
> [KT] Taking the scenario of the previous response, the inclusion of ECMP 
> origin node information would depend on how the ABR router receives the 
> intra-area prefix advertisements via LSAs from the nodes owning that prefix, 
> how they get processed by the SPF computation and then how they get included 
> in the inter-area route advertisements that the ABR generates. There are 
> various timers and scheduling mechanisms in the protocol for each of these 
> steps - but I would not call these timers/back-off mechanisms as "discovery".

I think by "discovery" I was thinking of a scenario where a router does a cold 
boot and has no local RIB at all -- will it advertise anything
(incomplete) while it is still learning routes, and will such incomplete 
advertisements cause issues when processe

[Lsr] Request for IANA early allocation for draft-ietf-lsr-ospf-reverse-metric

[Ketan Talaulikar (ketant)]

Hello,

We would like to request for IANA early allocations for the code points in this 
draft as indicated in 
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospf-reverse-metric-02#section-8

The suggested values are indicated in the draft.

Thanks,
Ketan (on behalf of co-authors)

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

[Lsr] Request for IANA early allocation for draft-ietf-lsr-ospf-l2bundles

[Ketan Talaulikar (ketant)]

Hello,

We would like to request for IANA early allocations for the code points in this 
draft as indicated in 
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospf-l2bundles#section-3

The suggested values are 24 and 29 for OSPFv2 and OSPFv3 respectively.

Thanks,
Ketan (on behalf of co-authors)

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

Re: [Lsr] John Scudder's No Objection on draft-ietf-lsr-ospf-prefix-originator-11: (with COMMENT)

[Ketan Talaulikar (ketant)]

Hi John,

Using this latest thread to respond since it captures all the open comments.

Please check inline below and we'll update the draft once we reach a conclusion 
on this.


-Original Message-
From: Aijun Wang  
Sent: 08 April 2021 07:41
To: 'John Scudder' ; 'The IESG' 
Cc: lsr-cha...@ietf.org; aretana.i...@gmail.com; 
draft-ietf-lsr-ospf-prefix-origina...@ietf.org; cho...@chopps.org; lsr@ietf.org
Subject: RE: [Lsr] John Scudder's No Objection on 
draft-ietf-lsr-ospf-prefix-originator-11: (with COMMENT)

Hi, John:

-Original Message-
From: lsr-boun...@ietf.org  On Behalf Of John Scudder via 
Datatracker
Sent: Thursday, April 8, 2021 8:38 AM
To: The IESG 
Cc: lsr-cha...@ietf.org; aretana.i...@gmail.com; 
draft-ietf-lsr-ospf-prefix-origina...@ietf.org; cho...@chopps.org; lsr@ietf.org
Subject: [Lsr] John Scudder's No Objection on 
draft-ietf-lsr-ospf-prefix-originator-11: (with COMMENT)

John Scudder has entered the following ballot position for
draft-ietf-lsr-ospf-prefix-originator-11: No Objection

When responding, please keep the subject line intact and reply to all email 
addresses included in the To and CC lines. (Feel free to cut this introductory 
paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-prefix-originator/



--
COMMENT:
--

Thanks for the update to the document and the discussion. Many points are 
resolved, remaining discussion summarized below. And by the way, I wondered the 
same as Ben regarding "In the ECMP case is there a way to correlate (order of
appearance?) the listed router-IDs with the listed reachable addresses?"

1. I've cleared my discuss but as mentioned in earlier email, would still 
suggest an update to the abstract:

"I would prefer to see a sentence in the abstract as well, since for some 
people the abstract is the only look they’ll take at the document and for them, 
the question of “what is it for?” isn’t answered. I don’t insist on this, but I 
recommend it. The additional sentence, if you choose to add it, could be 
something like “this information does not change route computation but is 
expected to be useful for network analysis and troubleshooting”."
[KT] Ack - will update the abstract in the next version and add : " These 
extensions do not change the core OSPF route computation functionality but 
provide useful information for network analysis, troubleshooting and use-case 
like traffic engineering (especially on a controller or an application external 
to OSPF)."

2. Section 2.1:

   For intra-area prefix advertisements, the Prefix Source OSPF Router-
   ID Sub-TLV MUST be considered invalid and ignored if the OSPF Router
   ID field is not the same as Advertising Router field in the
   containing LSA.  Similar validation cannot be reliably performed for
   inter-area and external prefix advertisements.

As discussed with Ketan, I'm not sure if "ignored" is vague only to me, or if 
it might be to other readers of the spec. I leave it to the authors' discretion 
whether and how to elaborate.
[KT] "Ignore" is indeed really the basic option available in OSPF when 
receiving semantically invalid information within a TLV in an LSA. We cannot 
discard or change it and neither can we ignore/discard the entire LSA on this 
account. We normally recommend raising error logs, however in this case since 
OSPF itself is not processing the information, it seemed better to leave it to 
the actual user of the information.

4. Section 3:

   When an ABR generates inter-area prefix advertisements into its non-
   backbone areas corresponding to an inter-area prefix advertisement
   from the backbone area, the only way to determine the originating
   node information is based on the Prefix Source OSPF Router-ID and
   Prefix Source Router Address Sub-TLVs present in the inter-area
   prefix advertisement originated into the backbone area by an ABR from
   another non-backbone area.  The ABR performs its prefix calculation
   to determine the set of nodes that contribute to the best prefix
   reachability.  It MUST use the prefix originator information only
   from this set of nodes.  The ABR MUST NOT include the Prefix Source
   OSPF Router-ID or the Prefix Source Router Address Sub-TLVs when it
   is unable to determine the information of the best originating node.

What is it supposed to do if there are N contributing routes but it can only 
determine the information for M < N of the contributors?

Ketan replied (my paraphrase) that in such a case partial information is sent.
My further question was "OK. And it’s considered fine that that information for 
some, but not all, of the contributors 

Re: [Lsr] John Scudder's Discuss on draft-ietf-lsr-ospf-prefix-originator-10: (with DISCUSS and COMMENT)

[Ketan Talaulikar (ketant)]

Hi John,



An update to the draft with to address some of your comments (as discussed in 
the email below) as well as Ben's and Eric's comments has just been posted : 
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospf-prefix-originator-11

Thanks,
Ketan

From: Ketan Talaulikar (ketant)
Sent: 07 April 2021 11:00
To: John Scudder ; The IESG 
Cc: draft-ietf-lsr-ospf-prefix-origina...@ietf.org; lsr-cha...@ietf.org; 
lsr@ietf.org; Christian Hopps ; aretana.i...@gmail.com
Subject: RE: John Scudder's Discuss on 
draft-ietf-lsr-ospf-prefix-originator-10: (with DISCUSS and COMMENT)


Hi John,



Thanks for your review and comments. Please check inline below.



-Original Message-
From: John Scudder via Datatracker mailto:nore...@ietf.org>>
Sent: 07 April 2021 02:36
To: The IESG mailto:i...@ietf.org>>
Cc: 
draft-ietf-lsr-ospf-prefix-origina...@ietf.org<mailto:draft-ietf-lsr-ospf-prefix-origina...@ietf.org>;
 lsr-cha...@ietf.org<mailto:lsr-cha...@ietf.org>; 
lsr@ietf.org<mailto:lsr@ietf.org>; Christian Hopps 
mailto:cho...@chopps.org>>; 
aretana.i...@gmail.com<mailto:aretana.i...@gmail.com>; 
cho...@chopps.org<mailto:cho...@chopps.org>
Subject: John Scudder's Discuss on draft-ietf-lsr-ospf-prefix-originator-10: 
(with DISCUSS and COMMENT)



John Scudder has entered the following ballot position for

draft-ietf-lsr-ospf-prefix-originator-10: Discuss



When responding, please keep the subject line intact and reply to all email 
addresses included in the To and CC lines. (Feel free to cut this introductory 
paragraph, however.)





Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html

for more information about IESG DISCUSS and COMMENT positions.





The document, along with other ballot positions, can be found here:

https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-prefix-originator/







--

DISCUSS:

--



Although the document is largely clear and well-written (thanks for that), I 
was left with one burning question: what are these sub-TLVs *for*? There’s no 
specification for what the router is supposed to do with them, only how to 
originate them. The only clue I get is buried down in Section 5:



   The identification of the node that is originating a specific prefix

   in the network may aid in debugging of issues related to prefix

   reachability within an OSPF network.



If their purpose is to act as debugging aids, I think you should at least say 
so briefly in the abstract and introduction. If they have some purpose beyond 
that, it’s missing from the doc.

[KT] I see that Aijun has responded on this one and we can use that thread for 
further discussion on this point.





--

COMMENT:

--



1. Section 2:



   This document defines the Prefix Source OSPF Router-ID and the Prefix

   Source Router Address Sub-TLVs for inclusion of the Router ID and a

   reachable address information for the router originating the prefix

   as a prefix attribute.



I found this sentence difficult to read. I think removing the redundant word 
“information” would help a little. Beyond that, it might help to break it into 
a couple sentences, as in: “This document defines the Prefix Source OSPF 
Router-ID and the Prefix Source Router Address Sub-TLVs. They are used, 
respectively, to include the Router ID of, and a reachable address of, the 
router that originates the prefix as a prefix attribute.”

[KT] Will update with your text proposal. Thanks.



2. Section 2.1:



   For intra-area prefix advertisements, the Prefix Source OSPF Router-

   ID Sub-TLV MUST be considered invalid and ignored if the OSPF Router

   ID field is not the same as Advertising Router field in the

   containing LSA.  Similar validation cannot be reliably performed for

   inter-area and external prefix advertisements.



What does it mean for the sub-TLV to be ignored? Since you haven’t specified 
any processing of the Sub-TLVs, there’s seemingly no ignoring to be done locally

[KT] The ignoring part is for the user of the information. Since the days of 
RSVP-TE (RFC3630), we've had OSPF flooding information about TE topology 
opaquely (i.e. not using for OSPF computations) while it is being used by for 
computation of RSVP-TE tunnel paths/LSPs. The same applies here.



— so does this mean the sub-TLV isn’t even supposed to be stored?

Flooded?

[KT] Per OSPF protocol, we have to store it and flood it - since the 
information is not "malformed" or "not parsable".



3. Section 3:



   If the originating node is advertising an OSPFv2 Router Address TLV

   [RFC3630] or an OSPFv3 Router IPv6 Address TLV [RFC5329], then the

   same address MUST be used in the 

Re: [Lsr] Benjamin Kaduk's No Objection on draft-ietf-lsr-ospf-prefix-originator-10: (with COMMENT)

[Ketan Talaulikar (ketant)]

Hi Ben,

Thanks for your review.

An update to the draft with to address some of yours, John's and Eric's 
comments has just been posted : 
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospf-prefix-originator-11

Please check inline below for responses.

-Original Message-
From: Lsr  On Behalf Of Benjamin Kaduk via Datatracker
Sent: 07 April 2021 11:38
To: The IESG 
Cc: lsr-cha...@ietf.org; aretana.i...@gmail.com; 
draft-ietf-lsr-ospf-prefix-origina...@ietf.org; cho...@chopps.org; lsr@ietf.org
Subject: [Lsr] Benjamin Kaduk's No Objection on 
draft-ietf-lsr-ospf-prefix-originator-10: (with COMMENT)

Benjamin Kaduk has entered the following ballot position for
draft-ietf-lsr-ospf-prefix-originator-10: No Objection

When responding, please keep the subject line intact and reply to all email 
addresses included in the To and CC lines. (Feel free to cut this introductory 
paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-prefix-originator/



--
COMMENT:
--

In the ECMP case is there a way to correlate (order of appearance?) the listed 
router-IDs with the listed reachable addresses?
[KT] No.

Are there cases where you might choose to only advertise one but not the other 
of the prefix source Router-ID and address?
[KT] Normally no. However, there is some text in Sec 5 about policies that may 
be employed to abstract/hide information (e.g. across areas/ASes) - such 
mechanisms may be used, as necessary, in a deployment.

Section 2.1

   The parent TLV of a prefix advertisement MAY include more than one
   Prefix Source OSPF Router-ID sub-TLV, one corresponding to each of
   the Equal-Cost Multi-Path (ECMP) nodes that originated the given
   prefix.

Is there any subtlety (or complexity, I guess) to how the advertising node 
knows about the other ECMP nodes advertising the same prefix?  
[KT] An ABR performs the inter-area prefix advertisements based on its local 
route computation (i.e. the sources contributing to its local intra-area 
route). It is not affected by the advertisement of the same prefix by another 
"peer/pair" ABR. I hope I've got your question right though.

For example, would there be some transient discovery stage when first setting 
up the ECMP advertisement and only a subset of the ECMP nodes are actually 
listed in some advertisements that go out?
[KT] Taking the scenario of the previous response, the inclusion of ECMP origin 
node information would depend on how the ABR router receives the intra-area 
prefix advertisements via LSAs from the nodes owning that prefix, how they get 
processed by the SPF computation and then how they get included in the 
inter-area route advertisements that the ABR generates. There are various 
timers and scheduling mechanisms in the protocol for each of these steps - but 
I would not call these timers/back-off mechanisms as "discovery".

Section 3

   another non-backbone area.  The ABR performs its prefix calculation
   to determine the set of nodes that contribute to the best prefix
   reachability.  It MUST use the prefix originator information only
   from this set of nodes.  The ABR MUST NOT include the Prefix Source
   OSPF Router-ID or the Prefix Source Router Address Sub-TLVs when it
   is unable to determine the information of the best originating node.

I feel like this text might be hiding some subtlety as to the nature of 
determining the "nodes that contribute to the best prefix reachability"
-- is this a concept that is well established in the core OSPF RFCs already 
(and thus doesn't need further explanation)?
[KT] Yes, it is a well-established part of the OSPF protocol/implementations.

Section 4

We often consider privacy considerations as part of the security considerations 
section.  Since routers are to some extent inherently "well known", they 
themselves may not have much privacy considerations but there may be something 
to say about propagating additional information about the internal structure of 
a given network.  My understanding is that OSPF areas are all under a common 
administrative domain, so this mostly only seems relevant to the case of 
AS-external advertisement.  One potential consideration would be if there is 
value in hiding that a set of prefixes are all advertised by the same router 
(the "linkability" of the prefixes, if you well).
(Hmm, I guess this is somewhat related to the existing operational 
considerations discussion, but not entirely equivalent.)
[KT] Yes, it is related. Hence the text in Sec 5 to cover the scenarios where 
there may be a desire to hide/abstract a set of prefixes' origin info while 
allowing for other prefixes.

If 

Re: [Lsr] John Scudder's Discuss on draft-ietf-lsr-ospf-prefix-originator-10: (with DISCUSS and COMMENT)

[Ketan Talaulikar (ketant)]

To add, the draft also has the following text in the introduction section:

   The primary use case for the extensions proposed in this document is
   to be able to identify the originator of a prefix in the network.  In
   cases where multiple prefixes are advertised by a given router, it is
   also useful to be able to associate all these prefixes with a single
   router even when prefixes are advertised outside of the area in which
   they originated.  It also helps to determine when the same prefix is
   being originated by multiple routers across areas.

The use-cases are similar in nature to those where the routing information 
being flooded/advertised by IGPs is used for/by other routing applications 
(e.g. TE) on the router or outside the router by an app/controller. The 
document does not describe those use-cases in further details since they are 
outside the scope of OSPF protocol and LSR WG.

The reason that the use-case that Aijun mentioned was asked to be removed from 
the document was on the same reasoning as above. Also, for that specific 
use-case, there was a lot of debate on the correctness and applicability as a 
generalized mechanism to be covered in this standards track document.

Hope this clarifies.

Thanks,
Ketan

From: Aijun Wang 
Sent: 07 April 2021 07:32
To: 'John Scudder' ; 'The IESG' 
Cc: lsr-cha...@ietf.org; aretana.i...@gmail.com; 
draft-ietf-lsr-ospf-prefix-origina...@ietf.org; cho...@chopps.org; lsr@ietf.org
Subject: RE: [Lsr] John Scudder's Discuss on 
draft-ietf-lsr-ospf-prefix-originator-10: (with DISCUSS and COMMENT)


Hi, John:



Thanks for your review.

Let me respond your concern for the usages of such information first.  Ketan, 
Acee and other co-authors may respond you other comments.



Actually, there are use case descriptions in the previous version of this 
draft, please refer to 
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospf-prefix-originator-05.

Section 
4
 and section 
5
 of this version describes its uses for inter-area topology recovery and 
external prefix source determination.



After discussion within the WG, we removes the use case descriptions within the 
body of the document, just keep some short descriptions as that in the 
introduction part of the current version:

“This document proposes extensions to the OSPF protocol for inclusion
   of information associated with the router originating the prefix
   along with the prefix advertisement.  These extensions do not change
   the core OSPF route computation functionality.  They provide useful
   information for topology analysis and traffic engineering, especially
   on a controller when this information is advertised as an attribute
   of the prefixes via mechanisms such as Border Gateway Protocol Link-
   State (BGP-LS)”

Do you think it is enough?



There is also one 
Appendix
 in the version 05 of this document, to describe clearly the usage of such 
prefix originator information, but was opposed by some experts during the WG 
last call.

Do we need to add back to them? I think they are helpful for the usage and 
deployment of this document. And, such use case is the main start point of this 
document.



Thanks in advance.


Best Regards

Aijun Wang
China Telecom



-Original Message-
From: lsr-boun...@ietf.org 
mailto:lsr-boun...@ietf.org>> On Behalf Of John Scudder 
via Datatracker
Sent: Wednesday, April 7, 2021 5:06 AM
To: The IESG mailto:i...@ietf.org>>
Cc: lsr-cha...@ietf.org; 
aretana.i...@gmail.com; 
draft-ietf-lsr-ospf-prefix-origina...@ietf.org;
 cho...@chopps.org; lsr@ietf.org
Subject: [Lsr] John Scudder's Discuss on 
draft-ietf-lsr-ospf-prefix-originator-10: (with DISCUSS and COMMENT)



John Scudder has entered the following ballot position for

draft-ietf-lsr-ospf-prefix-originator-10: Discuss



When responding, please keep the subject line intact and reply to all email 
addresses included in the To and CC lines. (Feel free to cut this introductory 
paragraph, however.)





Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html

for more information about IESG DISCUSS and COMMENT positions.





The document, along with other ballot positions, can be found here:

https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-prefix-originator/







--

DISCUSS:

--



Although the document is largely clear and well-written (thanks for that), I 
was left with 

Re: [Lsr] John Scudder's Discuss on draft-ietf-lsr-ospf-prefix-originator-10: (with DISCUSS and COMMENT)

[Ketan Talaulikar (ketant)]

Hi John,



Thanks for your review and comments. Please check inline below.



-Original Message-
From: John Scudder via Datatracker 
Sent: 07 April 2021 02:36
To: The IESG 
Cc: draft-ietf-lsr-ospf-prefix-origina...@ietf.org; lsr-cha...@ietf.org; 
lsr@ietf.org; Christian Hopps ; aretana.i...@gmail.com; 
cho...@chopps.org
Subject: John Scudder's Discuss on draft-ietf-lsr-ospf-prefix-originator-10: 
(with DISCUSS and COMMENT)



John Scudder has entered the following ballot position for

draft-ietf-lsr-ospf-prefix-originator-10: Discuss



When responding, please keep the subject line intact and reply to all email 
addresses included in the To and CC lines. (Feel free to cut this introductory 
paragraph, however.)





Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html

for more information about IESG DISCUSS and COMMENT positions.





The document, along with other ballot positions, can be found here:

https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-prefix-originator/







--

DISCUSS:

--



Although the document is largely clear and well-written (thanks for that), I 
was left with one burning question: what are these sub-TLVs *for*? There’s no 
specification for what the router is supposed to do with them, only how to 
originate them. The only clue I get is buried down in Section 5:



   The identification of the node that is originating a specific prefix

   in the network may aid in debugging of issues related to prefix

   reachability within an OSPF network.



If their purpose is to act as debugging aids, I think you should at least say 
so briefly in the abstract and introduction. If they have some purpose beyond 
that, it’s missing from the doc.

[KT] I see that Aijun has responded on this one and we can use that thread for 
further discussion on this point.





--

COMMENT:

--



1. Section 2:



   This document defines the Prefix Source OSPF Router-ID and the Prefix

   Source Router Address Sub-TLVs for inclusion of the Router ID and a

   reachable address information for the router originating the prefix

   as a prefix attribute.



I found this sentence difficult to read. I think removing the redundant word 
“information” would help a little. Beyond that, it might help to break it into 
a couple sentences, as in: “This document defines the Prefix Source OSPF 
Router-ID and the Prefix Source Router Address Sub-TLVs. They are used, 
respectively, to include the Router ID of, and a reachable address of, the 
router that originates the prefix as a prefix attribute.”

[KT] Will update with your text proposal. Thanks.



2. Section 2.1:



   For intra-area prefix advertisements, the Prefix Source OSPF Router-

   ID Sub-TLV MUST be considered invalid and ignored if the OSPF Router

   ID field is not the same as Advertising Router field in the

   containing LSA.  Similar validation cannot be reliably performed for

   inter-area and external prefix advertisements.



What does it mean for the sub-TLV to be ignored? Since you haven’t specified 
any processing of the Sub-TLVs, there’s seemingly no ignoring to be done locally

[KT] The ignoring part is for the user of the information. Since the days of 
RSVP-TE (RFC3630), we've had OSPF flooding information about TE topology 
opaquely (i.e. not using for OSPF computations) while it is being used by for 
computation of RSVP-TE tunnel paths/LSPs. The same applies here.



— so does this mean the sub-TLV isn’t even supposed to be stored?

Flooded?

[KT] Per OSPF protocol, we have to store it and flood it - since the 
information is not "malformed" or "not parsable".



3. Section 3:



   If the originating node is advertising an OSPFv2 Router Address TLV

   [RFC3630] or an OSPFv3 Router IPv6 Address TLV [RFC5329], then the

   same address MUST be used in the Router Address field of the Prefix

   Source Router Address Sub-TLV.  When the originating node is not

   advertising such an address, implementations can determine a unique

   and reachable address (i.e., advertised with the N-flag set [RFC7684]

   or N-bit set [RFC8362]) belonging to the originating node to set in

   the Router Address field.



As I read this, if there’s no Router Address TLV, then the implementation has 
to use something it advertised with the N-flag set. I infer this because you 
used “i.e.” (which essentially means “in other words”). If you do mean the 
parenthetical to be limiting, why not make it a MUST? If you don’t mean it to 
be limiting, shouldn’t it be “e.g.” or better still, “for example”?



(Looking at RFC 7684 it doesn’t seem as though it should be limiting, because 
RFC 7684 § 2.1 says the N-flag is optional even for local routes.)

[KT] It was 

Re: [Lsr] Éric Vyncke's No Objection on draft-ietf-lsr-ospf-prefix-originator-10: (with COMMENT)

[Ketan Talaulikar (ketant)]

Hi Eric,

Thanks for your review and please check inline below for 
response/clarifications.

-Original Message-
From: Éric Vyncke via Datatracker  
Sent: 05 April 2021 13:03
To: The IESG 
Cc: draft-ietf-lsr-ospf-prefix-origina...@ietf.org; lsr-cha...@ietf.org; 
lsr@ietf.org; Christian Hopps ; aretana.i...@gmail.com; 
cho...@chopps.org
Subject: Éric Vyncke's No Objection on 
draft-ietf-lsr-ospf-prefix-originator-10: (with COMMENT)

Éric Vyncke has entered the following ballot position for
draft-ietf-lsr-ospf-prefix-originator-10: No Objection

When responding, please keep the subject line intact and reply to all email 
addresses included in the To and CC lines. (Feel free to cut this introductory 
paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-prefix-originator/



--
COMMENT:
--

Thank you for the work put into this document. Easy to see the added value for 
trouble shooting !

Please find below some non-blocking COMMENT points (but replies would be 
appreciated).

I hope that this helps to improve the document,

Regards,

-éric

Thanks for fixing Warren Kumari's question in the latest -10.

-- Section 1 --
Is the reference to RFC 5329 correct ? I fail to see the link of TE with this 
document.
[KT] The reference to RFC5329 is required since it is the one that specified 
the "IPv6 Router Address" for OSPFv3 
(https://tools.ietf.org/html/rfc5329#section-3) which is semantically 
equivalent to what this document is specifying for usage in the Prefix Source 
Router Address Sub-TLV for OSPFv3. 

Should it be made clearer that the OSPFv3 router ID is a 32-bit value hence 
cannot be used in an IPv6-only network ? "it does not necessarily represent a 
reachable address for the router" is slightly ambiguous.
[KT] The point was that even for OSPFv2, it does not have to represent a 
reachable IPv4 address of the router. For OSPFv3, this is obviously not so too. 
Ack - will fix in the next update.

-- Section 2.2 --
Thanks for fixing Warren Kumari's question in the latest -10.

-- Section 4 --
Suggestion: made the sentence "A rogue node that can inject prefix..." in a 
separate paragraph.
[KT] Ack - will update in the next version.

Thanks,
Ketan



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

Re: [Lsr] Warren Kumari's No Record on draft-ietf-lsr-ospf-prefix-originator-09: (with COMMENT)

[Ketan Talaulikar (ketant)]

Hi Warren,


We’ve posted an update to the draft as discussed in the thread below : 
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospf-prefix-originator-10

Please let know if this addresses your comments.

Thanks,
Ketan

From: Ketan Talaulikar (ketant)
Sent: 01 April 2021 21:31
To: Aijun Wang ; 'Warren Kumari' 
Cc: 'Christian Hopps' ; aretana.i...@gmail.com; 
lsr-cha...@ietf.org; 'The IESG' ; lsr@ietf.org; 
draft-ietf-lsr-ospf-prefix-origina...@ietf.org
Subject: RE: [Lsr] Warren Kumari's No Record on 
draft-ietf-lsr-ospf-prefix-originator-09: (with COMMENT)

Hi Warren,

Thanks for your inputs. We’ll make the changes and share with you in the 
upcoming update.

Thanks,
Ketan

From: Aijun Wang mailto:wangai...@tsinghua.org.cn>>
Sent: 01 April 2021 06:50
To: 'Warren Kumari' mailto:war...@kumari.net>>; Ketan 
Talaulikar (ketant) mailto:ket...@cisco.com>>
Cc: 'Christian Hopps' mailto:cho...@chopps.org>>; 
aretana.i...@gmail.com<mailto:aretana.i...@gmail.com>; 
lsr-cha...@ietf.org<mailto:lsr-cha...@ietf.org>; 'The IESG' 
mailto:i...@ietf.org>>; lsr@ietf.org<mailto:lsr@ietf.org>; 
draft-ietf-lsr-ospf-prefix-origina...@ietf.org<mailto:draft-ietf-lsr-ospf-prefix-origina...@ietf.org>
Subject: RE: [Lsr] Warren Kumari's No Record on 
draft-ietf-lsr-ospf-prefix-originator-09: (with COMMENT)

Hi, Warren and Ketan:

As the co-author of this draft, I recommended to use “A received Prefix Source 
Router Address Sub-TLV that has an invalid length (i.e. not consistent with the 
prefix's address family) MUST be considered invalid and ignored”. or just 
remove it as Warren’s suggestion.


Best Regards

Aijun Wang
China Telecom

From: lsr-boun...@ietf.org<mailto:lsr-boun...@ietf.org> 
mailto:lsr-boun...@ietf.org>> On Behalf Of Warren Kumari
Sent: Thursday, April 1, 2021 4:32 AM
To: Ketan Talaulikar (ketant) mailto:ket...@cisco.com>>
Cc: Christian Hopps mailto:cho...@chopps.org>>; 
aretana.i...@gmail.com<mailto:aretana.i...@gmail.com>; 
lsr-cha...@ietf.org<mailto:lsr-cha...@ietf.org>; The IESG 
mailto:i...@ietf.org>>; lsr@ietf.org<mailto:lsr@ietf.org>; 
draft-ietf-lsr-ospf-prefix-origina...@ietf.org<mailto:draft-ietf-lsr-ospf-prefix-origina...@ietf.org>
Subject: Re: [Lsr] Warren Kumari's No Record on 
draft-ietf-lsr-ospf-prefix-originator-09: (with COMMENT)

... and apparently I'd lied to you, both in the Ballot itself, and also in this 
thread. I'd said that I had balloted NoObjection, but apparently  I'd hit No 
Comment instead. I'm fixing it now; mentioning just for the record...
W

On Wed, Mar 31, 2021 at 4:29 PM Warren Kumari 
mailto:war...@kumari.net>> wrote:


On Wed, Mar 31, 2021 at 2:46 AM Ketan Talaulikar (ketant) 
mailto:ket...@cisco.com>> wrote:
Hi Warren,

Thanks for your review and please check inline below. Will look forward to your 
inputs on how best to incorporate them in the draft.

-Original Message-
From: Warren Kumari via Datatracker mailto:nore...@ietf.org>>
Sent: 31 March 2021 00:53
To: The IESG mailto:i...@ietf.org>>
Cc: 
draft-ietf-lsr-ospf-prefix-origina...@ietf.org<mailto:draft-ietf-lsr-ospf-prefix-origina...@ietf.org>;
 lsr-cha...@ietf.org<mailto:lsr-cha...@ietf.org>; 
lsr@ietf.org<mailto:lsr@ietf.org>; Christian Hopps 
mailto:cho...@chopps.org>>; 
aretana.i...@gmail.com<mailto:aretana.i...@gmail.com>; 
cho...@chopps.org<mailto:cho...@chopps.org>
Subject: Warren Kumari's No Record on draft-ietf-lsr-ospf-prefix-originator-09: 
(with COMMENT)

Warren Kumari has entered the following ballot position for
draft-ietf-lsr-ospf-prefix-originator-09: No Record

When responding, please keep the subject line intact and reply to all email 
addresses included in the To and CC lines. (Feel free to cut this introductory 
paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-prefix-originator/



--
COMMENT:
--

I'm balloting No Objection, but I really would like a response...

1: I'm assuming I'm just missing something obvious here, but Section 2.2 sayeth:
"A received Prefix Source Router Address Sub-TLV that has an invalid length 
(i.e. not consistent with the prefix's address family) or a Router Address 
containing an invalid IPv4 or IPv6 address (dependent on address family of the 
associated prefix) MUST be considered invalid and ignored. "

What is an "invalid IPv4" address here? If the length is 4, and the route 
address is 0001 or 0xc0a80001, how do you know that that's not what I'm 
using? Again, I suspect that there is something ob

Re: [Lsr] Genart last call review of draft-ietf-lsr-ospf-prefix-originator-09

[Ketan Talaulikar (ketant)]

Hi Vijay,

Thanks for your review.

About the nit, this was the output of the xml2rfc tool - for some reason it 
does not seem to picking up the latest drafts/references. I didn't want to hand 
craft something like this.

Thanks,
Ketan

-Original Message-
From: Vijay Gurbani via Datatracker  
Sent: 02 April 2021 19:25
To: gen-...@ietf.org
Cc: draft-ietf-lsr-ospf-prefix-originator@ietf.org; last-c...@ietf.org; 
lsr@ietf.org
Subject: Genart last call review of draft-ietf-lsr-ospf-prefix-originator-09

Reviewer: Vijay Gurbani
Review result: Ready

I am the assigned Gen-ART reviewer for this draft. The General Area Review Team 
(Gen-ART) reviews all IETF documents being processed by the IESG for the IETF 
Chair.  Please treat these comments just like any other last call comments.

For more information, please see the FAQ at

.

Document: draft-ietf-lsr-ospf-prefix-originator-09
Reviewer: Vijay K. Gurbani
Review Date: 2021-04-02
IETF LC End Date: 2021-03-29
IESG Telechat date: 2021-04-08

Summary: This document is ready as a Proposed Standard.

Major issues: 0

Minor issues: 0

Nits/editorial comments: 1

Nits:
- idnits reports one warning: "== Outdated reference: A later version (-17) 
exists of draft-ietf-idr-bgp-ls-segment-routing-ext-16"

Thanks,

- vijay



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

Re: [Lsr] Warren Kumari's No Record on draft-ietf-lsr-ospf-prefix-originator-09: (with COMMENT)

[Ketan Talaulikar (ketant)]

Hi Warren,

Thanks for your inputs. We’ll make the changes and share with you in the 
upcoming update.

Thanks,
Ketan

From: Aijun Wang 
Sent: 01 April 2021 06:50
To: 'Warren Kumari' ; Ketan Talaulikar (ketant) 

Cc: 'Christian Hopps' ; aretana.i...@gmail.com; 
lsr-cha...@ietf.org; 'The IESG' ; lsr@ietf.org; 
draft-ietf-lsr-ospf-prefix-origina...@ietf.org
Subject: RE: [Lsr] Warren Kumari's No Record on 
draft-ietf-lsr-ospf-prefix-originator-09: (with COMMENT)

Hi, Warren and Ketan:

As the co-author of this draft, I recommended to use “A received Prefix Source 
Router Address Sub-TLV that has an invalid length (i.e. not consistent with the 
prefix's address family) MUST be considered invalid and ignored”. or just 
remove it as Warren’s suggestion.


Best Regards

Aijun Wang
China Telecom

From: lsr-boun...@ietf.org<mailto:lsr-boun...@ietf.org> 
mailto:lsr-boun...@ietf.org>> On Behalf Of Warren Kumari
Sent: Thursday, April 1, 2021 4:32 AM
To: Ketan Talaulikar (ketant) mailto:ket...@cisco.com>>
Cc: Christian Hopps mailto:cho...@chopps.org>>; 
aretana.i...@gmail.com<mailto:aretana.i...@gmail.com>; 
lsr-cha...@ietf.org<mailto:lsr-cha...@ietf.org>; The IESG 
mailto:i...@ietf.org>>; lsr@ietf.org<mailto:lsr@ietf.org>; 
draft-ietf-lsr-ospf-prefix-origina...@ietf.org<mailto:draft-ietf-lsr-ospf-prefix-origina...@ietf.org>
Subject: Re: [Lsr] Warren Kumari's No Record on 
draft-ietf-lsr-ospf-prefix-originator-09: (with COMMENT)

... and apparently I'd lied to you, both in the Ballot itself, and also in this 
thread. I'd said that I had balloted NoObjection, but apparently  I'd hit No 
Comment instead. I'm fixing it now; mentioning just for the record...
W

On Wed, Mar 31, 2021 at 4:29 PM Warren Kumari 
mailto:war...@kumari.net>> wrote:


On Wed, Mar 31, 2021 at 2:46 AM Ketan Talaulikar (ketant) 
mailto:ket...@cisco.com>> wrote:
Hi Warren,

Thanks for your review and please check inline below. Will look forward to your 
inputs on how best to incorporate them in the draft.

-Original Message-
From: Warren Kumari via Datatracker mailto:nore...@ietf.org>>
Sent: 31 March 2021 00:53
To: The IESG mailto:i...@ietf.org>>
Cc: 
draft-ietf-lsr-ospf-prefix-origina...@ietf.org<mailto:draft-ietf-lsr-ospf-prefix-origina...@ietf.org>;
 lsr-cha...@ietf.org<mailto:lsr-cha...@ietf.org>; 
lsr@ietf.org<mailto:lsr@ietf.org>; Christian Hopps 
mailto:cho...@chopps.org>>; 
aretana.i...@gmail.com<mailto:aretana.i...@gmail.com>; 
cho...@chopps.org<mailto:cho...@chopps.org>
Subject: Warren Kumari's No Record on draft-ietf-lsr-ospf-prefix-originator-09: 
(with COMMENT)

Warren Kumari has entered the following ballot position for
draft-ietf-lsr-ospf-prefix-originator-09: No Record

When responding, please keep the subject line intact and reply to all email 
addresses included in the To and CC lines. (Feel free to cut this introductory 
paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-prefix-originator/



--
COMMENT:
--

I'm balloting No Objection, but I really would like a response...

1: I'm assuming I'm just missing something obvious here, but Section 2.2 sayeth:
"A received Prefix Source Router Address Sub-TLV that has an invalid length 
(i.e. not consistent with the prefix's address family) or a Router Address 
containing an invalid IPv4 or IPv6 address (dependent on address family of the 
associated prefix) MUST be considered invalid and ignored. "

What is an "invalid IPv4" address here? If the length is 4, and the route 
address is 0001 or 0xc0a80001, how do you know that that's not what I'm 
using? Again, I suspect that there is something obvious that I'm missing here...
[KT] I did some digging around and was not really able to find a good reference 
to what would be "invalid IPv4" in this context. 0x0001 would be invalid 
but 0xc0a80001 would be valid. A multicast or ClassE or 0x would also 
be invalid. Basically, any address that cannot be used as Router Address (i.e. 
https://tools.ietf.org/html/rfc3630#section-2.4.1) would be invalid. Not sure 
if we should just remove the "invalid" part here or to attempt to go about 
specifying it.

I'd suggest just removing it -- trying to specify what "invalid" means in this 
case will likely lead to madness. If you really want to keep it, I'd suggest 
just saying something along the lines of "A received Prefix Source Router 
Address Sub-TLV that has an invalid length (i.e. not consistent with the 
prefix's address family) or a Route

Re: [Lsr] Warren Kumari's No Record on draft-ietf-lsr-ospf-prefix-originator-09: (with COMMENT)

[Ketan Talaulikar (ketant)]

Hi Warren,

Thanks for your review and please check inline below. Will look forward to your 
inputs on how best to incorporate them in the draft.

-Original Message-
From: Warren Kumari via Datatracker  
Sent: 31 March 2021 00:53
To: The IESG 
Cc: draft-ietf-lsr-ospf-prefix-origina...@ietf.org; lsr-cha...@ietf.org; 
lsr@ietf.org; Christian Hopps ; aretana.i...@gmail.com; 
cho...@chopps.org
Subject: Warren Kumari's No Record on draft-ietf-lsr-ospf-prefix-originator-09: 
(with COMMENT)

Warren Kumari has entered the following ballot position for
draft-ietf-lsr-ospf-prefix-originator-09: No Record

When responding, please keep the subject line intact and reply to all email 
addresses included in the To and CC lines. (Feel free to cut this introductory 
paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-prefix-originator/



--
COMMENT:
--

I'm balloting No Objection, but I really would like a response...

1: I'm assuming I'm just missing something obvious here, but Section 2.2 sayeth:
"A received Prefix Source Router Address Sub-TLV that has an invalid length 
(i.e. not consistent with the prefix's address family) or a Router Address 
containing an invalid IPv4 or IPv6 address (dependent on address family of the 
associated prefix) MUST be considered invalid and ignored. "

What is an "invalid IPv4" address here? If the length is 4, and the route 
address is 0001 or 0xc0a80001, how do you know that that's not what I'm 
using? Again, I suspect that there is something obvious that I'm missing here...
[KT] I did some digging around and was not really able to find a good reference 
to what would be "invalid IPv4" in this context. 0x0001 would be invalid 
but 0xc0a80001 would be valid. A multicast or ClassE or 0x would also 
be invalid. Basically, any address that cannot be used as Router Address (i.e. 
https://tools.ietf.org/html/rfc3630#section-2.4.1) would be invalid. Not sure 
if we should just remove the "invalid" part here or to attempt to go about 
specifying it.

2: This presumable has the side effect of increasing the size of the lsdb, 
possibly by a fairly large margin. It seems like it would have been nice to 
include an operational considerations section noting this, and, while you are 
at it, that this document will significantly aid in debugging
[KT] Almost all of the protocol extensions do result in increase of the LSDB 
size. However, depending on the use-case, these extensions may be used for 
select prefixes (e.g. the leaf networks to which traffic/service flows are 
destined to). The Sec 3 does have the following text that touches upon 
mitigation for this scaling part:

   Implementations MAY support the selection of specific prefixes for
   which the originating node information needs to be included with
   their prefix advertisements.

   Implementations MAY provide control on ABRs to selectively disable
   the propagation of the originating node information across area
   boundaries.

[KT] Regarding the debugging part - I agree. Should we add an operational 
considerations section here or just include this aspect in the introduction 
within the following text?

   The primary use case for the extensions proposed in this document is
   to be able to identify the originator of a prefix in the network.  In
   cases where multiple prefixes are advertised by a given router, it is
   also useful to be able to associate all these prefixes with a single
   router even when prefixes are advertised outside of the area in which
   they originated.  It also helps to determine when the same prefix is
   being originated by multiple routers across areas.

Thanks,
Ketan

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

Re: [Lsr] RtgDir review: draft-ietf-lsr-ospf-prefix-originator-09

[Ketan Talaulikar (ketant)]

Thanks Russ for your review.

-Original Message-
From: op...@riw.us  
Sent: 27 March 2021 17:06
To: rtg-...@ietf.org
Cc: rtg-...@ietf.org; draft-ietf-lsr-ospf-prefix-originator@ietf.org; 
lsr@ietf.org
Subject: RtgDir review: draft-ietf-lsr-ospf-prefix-originator-09

Hello,

I have been selected as the Routing Directorate reviewer for this draft. The 
Routing Directorate seeks to review all routing or routing-related drafts as 
they pass through IETF last call and IESG review, and sometimes on special 
request. The purpose of the review is to provide assistance to the Routing ADs. 
For more information about the Routing Directorate, please see 
​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir

Although these comments are primarily for the use of the Routing ADs, it would 
be helpful if you could consider them along with any other IETF Last Call 
comments that you receive, and strive to resolve them through discussion or by 
updating the draft.

Document: draft-ietf-lsr-ospf-prefix-originator-09
Reviewer: Russ White
Review Date: 26 March 2021
IETF LC End Date: 29 March 2021
Intended Status: Proposed Standard

Summary:

No issues found. This document is ready for publication.

This document is well written and concise in describing the uses, mechanisms, 
and protocol extensions.

Major Issues:

No major issues found.

Minor Issues:

No minor issues found.

 /r

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

Re: [Lsr] I-D Action: draft-ietf-lsr-ospf-bfd-strict-mode-03.txt

[Ketan Talaulikar (ketant)]

Hi All,

We've just posted an update to the draft with changes that are mostly editorial 
and nits.

However, there is one change in Sec 2 to call out for attention where we are 
clarifying that the B bit is set in the LLS options for both Hello and DD 
packets (i.e. the packets where LLS is allowed). 

Thanks,
Ketan (on behalf of co-authors)

-Original Message-
From: Lsr  On Behalf Of internet-dra...@ietf.org
Sent: 24 March 2021 13:33
To: i-d-annou...@ietf.org
Cc: lsr@ietf.org
Subject: [Lsr] I-D Action: draft-ietf-lsr-ospf-bfd-strict-mode-03.txt


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   : OSPF Strict-Mode for BFD
Authors : Ketan Talaulikar
  Peter Psenak
  Albert Fu
  Rajesh M
Filename: draft-ietf-lsr-ospf-bfd-strict-mode-03.txt
Pages   : 10
Date: 2021-03-24

Abstract:
   This document specifies the extensions to OSPF that enable an OSPF
   router to signal the requirement for a Bidirectional Forwarding
   Detection (BFD) session prior to adjacency formation.  Link-Local
   Signaling (LLS) is used to advertise the requirement of strict-mode
   for BFD session establishment for OSPF adjacency.  If both OSPF
   neighbors advertise the strict-mode for BFD, adjacency formation will
   be blocked until a BFD session has been successfully established.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-bfd-strict-mode/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-lsr-ospf-bfd-strict-mode-03
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospf-bfd-strict-mode-03

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-lsr-ospf-bfd-strict-mode-03


Please note that it may take a couple of minutes from the time of submission 
until the htmlized version and diff are available at tools.ietf.org.

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 mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Secdir last call review of draft-ietf-lsr-ospf-prefix-originator-09

[Ketan Talaulikar (ketant)]

Hi Watson,

Thanks for your review.

-Ketan

-Original Message-
From: Watson Ladd via Datatracker  
Sent: 20 March 2021 11:03
To: sec...@ietf.org
Cc: draft-ietf-lsr-ospf-prefix-originator@ietf.org; last-c...@ietf.org; 
lsr@ietf.org; watsonbl...@gmail.com
Subject: Secdir last call review of draft-ietf-lsr-ospf-prefix-originator-09

Reviewer: Watson Ladd
Review result: Ready

I have reviewed this document as part of the security directorate's ongoing 
effort to review all IETF documents being processed by the IESG.  These 
comments were written primarily for the benefit of the security area directors. 
 Document editors and WG chairs should treat these comments just like any other 
last call comments.

The summary of the review is Ready.

This document describes a small extension to OSPF to include information of the 
originating router for a prefix, which otherwise would be lost as the prefix 
proceeds to be readvertised. This information is quite useful when determining 
what is going on under trying circumstances.

Sincerely,
Watson Ladd


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

Re: [Lsr] AD Review of draft-ietf-lsr-ospf-prefix-originator-07

[Ketan Talaulikar (ketant)]

Hi Alvaro,

Thanks for that confirmation and the updated draft version has been posted with 
the changes.

https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospf-prefix-originator-09

Thanks,
Ketan

-Original Message-
From: Alvaro Retana  
Sent: 16 March 2021 23:23
To: Ketan Talaulikar (ketant) ; 
draft-ietf-lsr-ospf-prefix-origina...@ietf.org
Cc: John Scudder ; lsr-cha...@ietf.org; lsr@ietf.org; 
Christian Hopps 
Subject: RE: [Lsr] AD Review of draft-ietf-lsr-ospf-prefix-originator-07

 Ketan:

Hi!

I’m ok with your responses — I think we’re good to go.

Thanks!

Alvaro.


On March 9, 2021 at 12:42:21 PM, Ketan Talaulikar wrote:

> I will wait for your responses on a few of the points before posting 
> the draft update.
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] AD Review of draft-ietf-lsr-ospf-prefix-originator-07

[Ketan Talaulikar (ketant)]

Hi Alvaro,

Please check inline below with [KT2]

I will wait for your responses on a few of the points before posting the draft 
update.

-Original Message-
From: Alvaro Retana  
Sent: 09 March 2021 02:57
To: Ketan Talaulikar (ketant) ; 
draft-ietf-lsr-ospf-prefix-origina...@ietf.org
Cc: John Scudder ; lsr-cha...@ietf.org; lsr@ietf.org; 
Christian Hopps 
Subject: RE: [Lsr] AD Review of draft-ietf-lsr-ospf-prefix-originator-07

On March 8, 2021 at 12:35:52 PM, Ketan Talaulikar (ketant) wrote:


Ketan:

Hi!

I have a couple of comments below, which I think can be handled with other 
last-call comments.  I'm starting the IETF LC.

Thanks!!

Alvaro.




...
> 127 2. Protocol Extensions
>
> 129 This document defines the Prefix Source Router-ID and the Prefix
> 130 Originator Sub-TLVs for inclusion of the Router ID and a reachable
> 131 address information for the router originating the prefix as a 
> prefix
> 132 attribute.
>
> [major] I understand that the 2 sub-TLVs are optional and complement 
> each other. Is there an expectation for both to be present? Should 
> (SHOULD/MUST) both be present? What if they're not?
>
> [KT] There is no dependency between the two and hence either one or 
> both of them may be advertised.

Why do we need both then?  Can the users of this information figure stuff out 
with only one?  After all you added the Prefix Originator Sub-TLV for a reason. 
;-)
[KT2] One sub-TLV signals the OSPF Router-ID of the originating node in the 
OSPF domain, the other sub-TLV signals a reachable address of the originating 
node (may be within or even outside the OSPF domain for external prefixes). The 
draft explains this in the introduction and the procedures. I think perhaps it 
helps if we rename as

s/Prefix Source Router-ID Sub-TLV/Prefix Source OSPF Router-ID Sub-TLV
s/Prefix Originator Sub-TLV/Prefix Source Router Address Sub-TLV

...
> 134 2.1. Prefix Source Router-ID Sub-TLV ...
> 161 o OSPF Router ID : the OSPF Router ID of the OSPF router that
> 162 originated the prefix advertisement in the OSPF domain.
>
> [major] Should there be a relationship between the router ID and the 
> Advertising Router field in the LSA containing the prefix? What does 
> it mean if the router ID doesn't match?
>
> [KT] The value MUST match for intra-area. So we can clarify this part 
> and if it does not match then the sub-TLV can be ignored. For external (e.g.
> Type 5), we cannot determine because we don't know if it was not 
> translated from Type 7 to Type 5 by an NSSA ABR. Same way we cannot 
> figure this out reliably for inter-area prefix advertisements. Not 
> sure if there is anything we can say other than intra-area.

Right.

OLD>
   For intra-area prefix advertisements, the Prefix Source Router-ID
   Sub-TLV MUST be considered invalid and ignored if it is not the same
   as Advertising Router ID for the prefix advertisement.

NEW>
   For intra-area prefix advertisements, the Prefix Source Router-ID Sub-TLV
   MUST be considered invalid and ignored if the OSPF Router ID field is not
   the same as the Advertising Router field in the containing LSA.
[KT2] Ack


For inter-area, maybe it's worth mentioning the fact that it cannot be 
verified, so a rogue ABR (see more on rogue below) can inject incorrect 
information.
[KT2] Ack. Will add - " Similar validation cannot be reliably performed for 
inter-area and external prefix advertisements." At the end of the above 
paragraph. 


> [major] Even though this document doesn't specify any 
> OSPF-in-the-network action based on the new information, it does say 
> that the information is useful for "topology analysis and traffic 
> engineering", which means that the values may have an impact on route 
> calculation (at a controller). I'm asking the questions about matching 
> values because (if they don't) then it would be relatively easy for a 
> rogue node to introduce non-congruent values which could have an effect on 
> the controller's decision.
>
> [KT] We need to remember that we are talking about a prefix 
> advertisement - a rogue would need to make a prefix advertisement 
> first (which is considered for OSPF routing) and only then comes the 
> part when this sub-TLV value is mismatched. Isn't the first part a bigger 
> issue?

Yes.  But a rogue node can already do that!!  This draft adds the second part.

Note that by rogue I mean a router that has been subverted; e.g.
someone got the password and now has the ability to inject anything into the 
network.  In this case authentication does not help because the router has the 
proper keys.

Note that I'm not asking you to fix the problem -- just to mention the new risk.
[KT2] I am assuming you are asking for this to be mentioned in the Securities 
Considerations section. I am not sure what would be a helpful text here. Does 
the followin

Re: [Lsr] AD Review of draft-ietf-lsr-ospf-prefix-originator-07

[Ketan Talaulikar (ketant)]

Hi Alvaro,

Thanks for your detail review and comments. We've update the draft to address 
your comments and the version 8 posted below.

https://www.ietf.org/archive/id/draft-ietf-lsr-ospf-prefix-originator-08.txt

Please check inline below for responses.

Thanks,
Ketan


-邮件原件-
发件人: lsr-boun...@ietf.org [mailto:lsr-boun...@ietf.org] 代表 Alvaro Retana
发送时间: 2021年2月13日 20:36
收件人: draft-ietf-lsr-ospf-prefix-origina...@ietf.org
抄送: lsr-cha...@ietf.org; John Scudder; Christian Hopps; lsr@ietf.org
主题: [Lsr] AD Review of draft-ietf-lsr-ospf-prefix-originator-07

Dear authors:

Thank you for working on this document.  I have some comments (below) that I 
would like to see addressed before starting the IETF Last Call.

Thanks!

Alvaro.


[Line numbers from idnits.]

...
70  1.  Introduction
...
77 The identification of the originating router for a prefix in OSPF
78 varies by the type of the prefix and is currently not always
79 possible.  For intra-area prefixes, the originating router is
80 identified by the advertising Router ID field of the area-scoped LSA
81 used for those prefix advertisements.  However, for the inter-area
82 prefixes advertised by the Area Border Router (ABR), the advertising
83 Router ID field of their area-scoped LSAs is set to the ABR itself
84 and the information about the router originating the prefix
85 advertisement is lost in this process of prefix propagation across
86 areas.  For Autonomous System (AS) external prefixes, the originating
87 router may be considered as the Autonomous System Border Router
88 (ASBR) and is identified by the advertising Router ID field of the
89 AS-scoped LSA used.  However, the actual originating router for the
90 prefix may be a remote router outside the OSPF domain.  Similarly,
91 when an ABR performs translation of Not-So-Stubby Area (NSSA)
92 [RFC3101] LSAs to AS-external LSAs, the information associated with
93 the NSSA ASBR (or the router outside the OSPF domain) is not conveyed
94 across the OSPF domain.

[minor] s/advertising Router ID field/Advertising Router field/g
[KT] Ack


...
102The primary use case for the extensions proposed in this document is
103to be able to identify the originator of the prefix in the network.
104In cases where multiple prefixes are advertised by a given router, it
105is also useful to be able to associate all these prefixes with a
106single router even when prefixes are advertised outside of the area
107in which they originated.  It also helps to determine when the same
108prefix is being originated by multiple routers across areas.

[nit] s/of the prefix/of a prefix
[KT] Ack


110This document proposes extensions to the OSPF protocol for inclusion
111of information associated with the router originating the prefix
112along with the prefix advertisement.  These extensions do not change
113the core OSPF route computation functionality.  They provide useful
114information for topology analysis and traffic engineering, especially
115on a controller when this information is advertised as an attribute
116of the prefixes via mechanisms such as Border Gateway Protocol Link-
117State (BGP-LS) [RFC7752].

[minor] "advertised...via...BGP-LS"  Please add an Informative reference to 
draft-ietf-idr-bgp-ls-segment-routing-ext.
[KT] Ack

[FYI] The second sub-tLV is not included in the BGP-LS extension draft
-- I will send a note to the authors.
[KT] I am also co-author on that draft and will respond on that one.


...
127 2.  Protocol Extensions

129This document defines the Prefix Source Router-ID and the Prefix
130Originator Sub-TLVs for inclusion of the Router ID and a reachable
131address information for the router originating the prefix as a prefix
132attribute.

[major] I understand that the 2 sub-TLVs are optional and complement each 
other.  Is there an expectation for both to be present?  Should
(SHOULD/MUST) both be present?  What if they're not?
[KT] There is no dependency between the two and hence either one or both of 
them may be advertised.


...
134 2.1.  Prefix Source Router-ID Sub-TLV
...
161o  OSPF Router ID : the OSPF Router ID of the OSPF router that
162   originated the prefix advertisement in the OSPF domain.

[major] Should there be a relationship between the router ID and the 
Advertising Router field in the LSA containing the prefix?  What does it mean 
if the router ID doesn't match?
[KT] The value MUST match for intra-area. So we can clarify this part and if it 
does not match then the sub-TLV can be ignored. For external (e.g. Type 5), we 
cannot determine because we don't know if it was not translated from Type 7 to 
Type 5 by an NSSA ABR. Same way we cannot figure this 

Re: [Lsr] Link Data value for Multi-area links

[Ketan Talaulikar (ketant)]

Hi Aijun,

OSPF MIB RFC4750 was published before MADJ was introduced in OSPF. I would 
think it is quite natural that it does not consider MADJ. If your proposal is 
to fix/extend OSPF MIB in 202x for MADJ then do please go ahead.

As a reference you can look at how this is handled in the OSPF YANG model : 
https://tools.ietf.org/html/draft-ietf-ospf-yang-29#section-2.7

MADJ is a well-known, widely implemented and deployed feature. What we have 
been debating is more of a “point fix” to RFC5185.

So I do not follow what is it exactly that you are proposing?

Thanks,
Ketan

From: Aijun Wang 
Sent: 04 December 2020 12:31
To: Ketan Talaulikar (ketant) ; 'Acee Lindem (acee)' 
; 'Alexander Okonnikov' 
; 'Van De Velde, Gunter (Nokia - BE/Antwerp)' 

Cc: lsr@ietf.org; Peter Psenak (ppsenak) 
Subject: RE: [Lsr] Link Data value for Multi-area links

Hi, Ketan:

Using the local ip address or IfIndex can solve the correlation with the Link 
TLV in RFC3630, but it still does not resolve the ambiguity problem that 
required by RFC4750(OSPF MIB) as Acee mentioned.
Do we still follow this way?


Best Regards

Aijun Wang
China Telecom

From: Ketan Talaulikar (ketant) mailto:ket...@cisco.com>>
Sent: Thursday, December 3, 2020 5:35 PM
To: Aijun Wang mailto:wangai...@tsinghua.org.cn>>; 
'Acee Lindem (acee)' 
mailto:acee=40cisco@dmarc.ietf.org>>; 
'Alexander Okonnikov' 
mailto:alexander.okonni...@gmail.com>>; 'Van De 
Velde, Gunter (Nokia - BE/Antwerp)' 
mailto:gunter.van_de_ve...@nokia.com>>
Cc: lsr@ietf.org<mailto:lsr@ietf.org>; Peter Psenak (ppsenak) 
mailto:ppse...@cisco.com>>
Subject: RE: [Lsr] Link Data value for Multi-area links

Hi Aijun,

Please check my previous response on this thread.

The matter is quite simple and easily addressed.

IMHO we do not need to invent a new protocol contraption or repurpose your 
stub-link proposal for this situation.

Thanks,
Ketan

From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of 
Aijun Wang
Sent: 01 December 2020 09:22
To: 'Acee Lindem (acee)' 
mailto:acee=40cisco@dmarc.ietf.org>>; 
'Alexander Okonnikov' 
mailto:alexander.okonni...@gmail.com>>; 'Van De 
Velde, Gunter (Nokia - BE/Antwerp)' 
mailto:gunter.van_de_ve...@nokia.com>>
Cc: lsr@ietf.org<mailto:lsr@ietf.org>; Peter Psenak (ppsenak) 
mailto:ppse...@cisco.com>>
Subject: Re: [Lsr] Link Data value for Multi-area links

Hi,

How about using the stub-link that we proposed and discussed at 
https://mailarchive.ietf.org/arch/msg/lsr/LppwUNb_ngr8m4awaprvSHGFfhg/ to solve 
the scenario that described in RFC5185?
The possible solution is the following:
1)  The ABR form only the normal adjacency within the backbone area.
2)  For other area(for example, area 1) that they belong, each of them 
advertise the stub-link TLV, which include the network prefix that other 
area(area 1) belongs to, and also the metric to such prefix.
3)  The OSPF treat the prefixes within this stub-link TLV as the intra-area 
prefix in other area(area 1) and will prefer to using them over the inter-area 
prefix in the non-multi-area solution.
4)  More areas can be configured on such ABRs, eliminate the necessary to 
configure interface address within each area, also eliminate the ambiguity for 
using the remote peer address to differentiate the different adjacency.
5)  It is also easy to correlate such link information with the TE 
information that advertised in RFC3630.
Are the above proposal acceptable?

Best Regards

Aijun Wang
China Telecom

From: lsr-boun...@ietf.org<mailto:lsr-boun...@ietf.org> 
mailto:lsr-boun...@ietf.org>> On Behalf Of Acee Lindem 
(acee)
Sent: Tuesday, December 1, 2020 1:58 AM
To: Alexander Okonnikov 
mailto:alexander.okonni...@gmail.com>>; Van De 
Velde, Gunter (Nokia - BE/Antwerp) 
mailto:gunter.van_de_ve...@nokia.com>>
Cc: lsr@ietf.org<mailto:lsr@ietf.org>; Peter Psenak (ppsenak) 
mailto:ppse...@cisco.com>>
Subject: Re: [Lsr] Link Data value for Multi-area links

Speaking on WG member:

Hi Alex,
I knew this was coming. In 2008, 99.9% of the requirements were handled by 
supporting an interface in a primary area and one other area. Using the remote 
IP address for the other area does handle this case. As I stated previously, if 
you support OSPF adjacencies on secondary IP addresses, the MIB and other 
complexities are all taken care of and that would be the solution that I would 
recommend. However, if you guys want to spend time trying to improve RFC5185, 
you are perfectly welcome to submit a draft.

Thanks,
Acee

From: Alexander Okonnikov 
mailto:alexander.okonni...@gmail.com>>
Date: Monday, November 30, 2020 at 12:47 PM
To: Gunter Van de Velde 
mailto:gunter.van_de_ve...@nokia.com>>
Cc: Acee Lindem mailto:a...@cisco.com>>, "Peter Psenak 
(ppsenak)" mailto:ppse...@cisco.com>>, 
"lsr@ietf.org<mailto:lsr@ietf.org>" mailto:lsr@ietf.org

Re: [Lsr] Link Data value for Multi-area links

[Ketan Talaulikar (ketant)]

Hi Peter,

Please check inline below.

-Original Message-
From: Peter Psenak  
Sent: 03 December 2020 15:48
To: Ketan Talaulikar (ketant) ; Acee Lindem (acee) 
; Van De Velde, Gunter (Nokia - BE/Antwerp) 
; Alexander Okonnikov 
; Acee Lindem (acee) 
Cc: lsr@ietf.org
Subject: Re: [Lsr] Link Data value for Multi-area links

Hi Ketan,

On 03/12/2020 10:31, Ketan Talaulikar (ketant) wrote:
> Hello All,
> 
> The text in RFC5185 for picking the neighbor’s IP Address or IfIndex 
> for the link-data is indeed very odd and flies against how things are 
> done for normal p2p links per RFC2328.
> 
> The implementations that I am aware of do not really following this 
> “decision” of RFC5185 and instead stick to RFC2328 architecture by 
> picking the local IP address or IfIndex even for MADJ links. This way, 
> a remote router cannot really distinguish between a normal P2P link or 
> a MADJ – they look the same in the LSDB.
> 
> While the neighbor IP address can be learnt via the source address 
> used for the hello messages, there is really no simple way to learn 
> the neighbor’s IfIndex for unnumbered links [1].

rfc8510?
[KT] Yes

> 
> So IMHO the RFC5185 is in error and we should fix this if we have 
> consensus in the WG via a BIS as suggested by Acee.


I'm not convinced about the error. Nor about the need of the bis.
[KT] The question is why is RFC5185 not aligned with base OSPF RFC2328 on this 
aspect? What was the need for MADJ to have a reverse link-data information as 
compared to normal P2P links?

Thanks,
Ketan

my 2c,
Peter


> 
> Gunter, I am not getting into your other questions because of what 
> I’ve mentioned above 
> 
> Thanks,
> 
> Ketan
> 
> [1] Note that over time we have introduced such mechanisms (RFC8510), 
> but they have all been optional and not “base/required” behavior.
> 
> *From:*Lsr  *On Behalf Of *Acee Lindem (acee)
> *Sent:* 30 November 2020 23:18
> *To:* Van De Velde, Gunter (Nokia - BE/Antwerp) 
> ; Alexander Okonnikov 
> ; Peter Psenak (ppsenak) 
> ; Acee Lindem (acee) 
> *Cc:* lsr@ietf.org
> *Subject:* Re: [Lsr] Link Data value for Multi-area links
> 
> You are welcome to propose an alternate solution which could possibly 
> be accepted as a BIS document. However, this is not something that can 
> be simply changed in an Errata to reduce the complexity.
> 
> Thanks,
> Acee
> 
> *From: *Lsr mailto:lsr-boun...@ietf.org>> on 
> behalf of Gunter Van de Velde  <mailto:gunter.van_de_ve...@nokia.com>>
> *Date: *Monday, November 30, 2020 at 12:21 PM
> *To: *"Acee Lindem (acee)"  <mailto:acee=40cisco@dmarc.ietf.org>>, Alexander Okonnikov 
>  <mailto:alexander.okonni...@gmail.com>>,
> "Peter Psenak (ppsenak)"  <mailto:ppse...@cisco.com>>
> *Cc: *"lsr@ietf.org <mailto:lsr@ietf.org>"  <mailto:lsr@ietf.org>>
> *Subject: *Re: [Lsr] Link Data value for Multi-area links
> 
> The oddnes is that the architecture decision in RFC5185 to select 
> remote-ip-address instead of local-ip-address for the ‘Link Data’ is 
> making things much more complicated.
> 
> I am surprised to see that using the remote-ip-address is seen as the 
> ‘better’ choice as selecting local-ip-address. To me it seems as a 
> worse choice.
> 
> A question that was asked: How router will be able to match Link TLV 
> (RFC 3630) to corresponding Link in Router LSA?
> 
> Answer:
> 
> For unnumbered links we can match Link TLV with Router TLV using the 
> IfIndex when there is no stub type 3 link (=easy)
> 
> For numbered:
> 
> 1.we must first look if the there is a stub type 3 link
> 
> 2.If stub type 3 exists, then the RFC3630 local ip address must be 
> used to identify the correspond link within the router TLV to the 
> neighbor
> 
> 3.If the stub type 3 link did not exist in Router TLV link, then the 
> maybe the link is unnumbered, and we try to match upon IfIndex… This 
> may give a match or no match
> 
> 4.If there is no match, then maybe the link is MADJ and we must use 
> the
> RFC3630 remote IP address to match upon the Link Data
> 
> 5.= over-complex. (If we used  for RFC5185 ‘Link Data = local ip 
> address’ then (2) would given answer directly)
> 
> In addition, for a router it is much simpler to learn and advertise 
> local-ip-address in Router LSAs then using a remote-ip-address.
> 
> I also believe that if we want to search something in TEDB after 
> receiving a TE Link TLV. How can we identify from the TE Link TLV if 
> multi-area or not multi-area? If we can not, then how can we create 
> the correct key?
> 
> Looking at the above, the choice of using remote-ip-address for 
> RFC5185 Link Data seems not the best design

Re: [Lsr] Link Data value for Multi-area links

[Ketan Talaulikar (ketant)]

Hi Aijun,

Please check my previous response on this thread.

The matter is quite simple and easily addressed.

IMHO we do not need to invent a new protocol contraption or repurpose your 
stub-link proposal for this situation.

Thanks,
Ketan

From: Lsr  On Behalf Of Aijun Wang
Sent: 01 December 2020 09:22
To: 'Acee Lindem (acee)' ; 'Alexander 
Okonnikov' ; 'Van De Velde, Gunter (Nokia - 
BE/Antwerp)' 
Cc: lsr@ietf.org; Peter Psenak (ppsenak) 
Subject: Re: [Lsr] Link Data value for Multi-area links

Hi,

How about using the stub-link that we proposed and discussed at 
https://mailarchive.ietf.org/arch/msg/lsr/LppwUNb_ngr8m4awaprvSHGFfhg/ to solve 
the scenario that described in RFC5185?
The possible solution is the following:

  1.  The ABR form only the normal adjacency within the backbone area.
  2.  For other area(for example, area 1) that they belong, each of them 
advertise the stub-link TLV, which include the network prefix that other 
area(area 1) belongs to, and also the metric to such prefix.
  3.  The OSPF treat the prefixes within this stub-link TLV as the intra-area 
prefix in other area(area 1) and will prefer to using them over the inter-area 
prefix in the non-multi-area solution.
  4.  More areas can be configured on such ABRs, eliminate the necessary to 
configure interface address within each area, also eliminate the ambiguity for 
using the remote peer address to differentiate the different adjacency.
  5.  It is also easy to correlate such link information with the TE 
information that advertised in RFC3630.
Are the above proposal acceptable?

Best Regards

Aijun Wang
China Telecom

From: lsr-boun...@ietf.org 
mailto:lsr-boun...@ietf.org>> On Behalf Of Acee Lindem 
(acee)
Sent: Tuesday, December 1, 2020 1:58 AM
To: Alexander Okonnikov 
mailto:alexander.okonni...@gmail.com>>; Van De 
Velde, Gunter (Nokia - BE/Antwerp) 
mailto:gunter.van_de_ve...@nokia.com>>
Cc: lsr@ietf.org; Peter Psenak (ppsenak) 
mailto:ppse...@cisco.com>>
Subject: Re: [Lsr] Link Data value for Multi-area links

Speaking on WG member:

Hi Alex,
I knew this was coming. In 2008, 99.9% of the requirements were handled by 
supporting an interface in a primary area and one other area. Using the remote 
IP address for the other area does handle this case. As I stated previously, if 
you support OSPF adjacencies on secondary IP addresses, the MIB and other 
complexities are all taken care of and that would be the solution that I would 
recommend. However, if you guys want to spend time trying to improve RFC5185, 
you are perfectly welcome to submit a draft.

Thanks,
Acee

From: Alexander Okonnikov 
mailto:alexander.okonni...@gmail.com>>
Date: Monday, November 30, 2020 at 12:47 PM
To: Gunter Van de Velde 
mailto:gunter.van_de_ve...@nokia.com>>
Cc: Acee Lindem mailto:a...@cisco.com>>, "Peter Psenak 
(ppsenak)" mailto:ppse...@cisco.com>>, 
"lsr@ietf.org" mailto:lsr@ietf.org>>
Subject: Re: [Lsr] Link Data value for Multi-area links

Hi Acee,

RFC 5185 says that interface data structure is created for each multi-area 
adjacency. I guess that we are not allowed to allocate several ifIndex values 
for the same IP interface, because it is property of router's interface, not 
OSPF interface. Hence, we have several OSPF interfaces with the same ifIndex in 
unnumbered case and, thus, ambiguity in Interface table. The same for numbered 
- we have IP interface address (one), which is the same for multiple OSPF 
interfaces, and we again obtain ambiguity. Per my understanding advertising 
neighbor's IP address (or ifIndex) in Link Data doesn't help here.

30 нояб. 2020 г., в 20:20, Van De Velde, Gunter (Nokia - BE/Antwerp) 
mailto:gunter.van_de_ve...@nokia.com>> 
написал(а):

The oddnes is that the architecture decision in RFC5185 to select 
remote-ip-address instead of local-ip-address for the ‘Link Data’ is making 
things much more complicated.
I am surprised to see that using the remote-ip-address is seen as the ‘better’ 
choice as selecting local-ip-address. To me it seems as a worse choice.

A question that was asked: How router will be able to match Link TLV (RFC 3630) 
to corresponding Link in Router LSA?

Answer:
For unnumbered links we can match Link TLV with Router TLV using the IfIndex 
when there is no stub type 3 link (=easy)
For numbered:

1.  we must first look if the there is a stub type 3 link

2.  If stub type 3 exists, then the RFC3630 local ip address must be used 
to identify the correspond link within the router TLV to the neighbor

3.  If the stub type 3 link did not exist in Router TLV link, then the 
maybe the link is unnumbered, and we try to match upon IfIndex… This may give a 
match or no match

4.  If there is no match, then maybe the link is MADJ and we must use the 
RFC3630 remote IP address to match upon the Link Data

5.  = over-complex. (If we used  for RFC5185 ‘Link Data = local ip address’ 
then (2) would given 

Re: [Lsr] Link Data value for Multi-area links

[Ketan Talaulikar (ketant)]

Hello All,

The text in RFC5185 for picking the neighbor’s IP Address or IfIndex for the 
link-data is indeed very odd and flies against how things are done for normal 
p2p links per RFC2328.

The implementations that I am aware of do not really following this “decision” 
of RFC5185 and instead stick to RFC2328 architecture by picking the local IP 
address or IfIndex even for MADJ links. This way, a remote router cannot really 
distinguish between a normal P2P link or a MADJ – they look the same in the 
LSDB.

While the neighbor IP address can be learnt via the source address used for the 
hello messages, there is really no simple way to learn the neighbor’s IfIndex 
for unnumbered links [1].

So IMHO the RFC5185 is in error and we should fix this if we have consensus in 
the WG via a BIS as suggested by Acee.

Gunter, I am not getting into your other questions because of what I’ve 
mentioned above 

Thanks,
Ketan

[1] Note that over time we have introduced such mechanisms (RFC8510), but they 
have all been optional and not “base/required” behavior.

From: Lsr  On Behalf Of Acee Lindem (acee)
Sent: 30 November 2020 23:18
To: Van De Velde, Gunter (Nokia - BE/Antwerp) ; 
Alexander Okonnikov ; Peter Psenak (ppsenak) 
; Acee Lindem (acee) 
Cc: lsr@ietf.org
Subject: Re: [Lsr] Link Data value for Multi-area links

You are welcome to propose an alternate solution which could possibly be 
accepted as a BIS document. However, this is not something that can be simply 
changed in an Errata to reduce the complexity.
Thanks,
Acee

From: Lsr mailto:lsr-boun...@ietf.org>> on behalf of 
Gunter Van de Velde 
mailto:gunter.van_de_ve...@nokia.com>>
Date: Monday, November 30, 2020 at 12:21 PM
To: "Acee Lindem (acee)" 
mailto:acee=40cisco@dmarc.ietf.org>>, 
Alexander Okonnikov 
mailto:alexander.okonni...@gmail.com>>, "Peter 
Psenak (ppsenak)" mailto:ppse...@cisco.com>>
Cc: "lsr@ietf.org" mailto:lsr@ietf.org>>
Subject: Re: [Lsr] Link Data value for Multi-area links

The oddnes is that the architecture decision in RFC5185 to select 
remote-ip-address instead of local-ip-address for the ‘Link Data’ is making 
things much more complicated.
I am surprised to see that using the remote-ip-address is seen as the ‘better’ 
choice as selecting local-ip-address. To me it seems as a worse choice.

A question that was asked: How router will be able to match Link TLV (RFC 3630) 
to corresponding Link in Router LSA?

Answer:
For unnumbered links we can match Link TLV with Router TLV using the IfIndex 
when there is no stub type 3 link (=easy)
For numbered:

1.  we must first look if the there is a stub type 3 link

2.  If stub type 3 exists, then the RFC3630 local ip address must be used 
to identify the correspond link within the router TLV to the neighbor

3.  If the stub type 3 link did not exist in Router TLV link, then the 
maybe the link is unnumbered, and we try to match upon IfIndex… This may give a 
match or no match

4.  If there is no match, then maybe the link is MADJ and we must use the 
RFC3630 remote IP address to match upon the Link Data

5.  = over-complex. (If we used  for RFC5185 ‘Link Data = local ip address’ 
then (2) would given answer directly)

In addition, for a router it is much simpler to learn and advertise 
local-ip-address in Router LSAs then using a remote-ip-address.
I also believe that if we want to search something in TEDB after receiving a TE 
Link TLV. How can we identify from the TE Link TLV if multi-area or not 
multi-area? If we can not, then how can we create the correct key?

Looking at the above, the choice of using remote-ip-address for RFC5185 Link 
Data seems not the best design that we can do, and is adding OSPF complexity 
without benefits.

Should this not be corrected in RFC5185 and simply use local-ip-address instead 
of the remote-ip-address for Multi-area Link Data and avoid the additional 
unnecessary complexity the current RFC for numbered links?

Brgds,
G/


From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of Acee 
Lindem (acee)
Sent: Monday, November 30, 2020 18:01
To: Alexander Okonnikov 
mailto:alexander.okonni...@gmail.com>>; Peter 
Psenak (ppsenak) mailto:ppse...@cisco.com>>
Cc: lsr@ietf.org
Subject: Re: [Lsr] Link Data value for Multi-area links

Hi Alex,

Multi-Area interface disambiguation is required to support the OSPF MIB as 
specified in RFC 4750. The table indexing doesn’t include the area. For example:

--  OSPF Interface Table

  ospfIfTable OBJECT-TYPE
   SYNTAX   SEQUENCE OF OspfIfEntry
   MAX-ACCESS   not-accessible
   STATUS   current
   DESCRIPTION
  "The OSPF Interface Table describes the interfaces
  from the viewpoint of OSPF.
  It augments the ipAddrTable with OSPF specific information."
   REFERENCE
  "OSPF Version 2, Appendix C.3  Router interface
  parameters"
   ::= { ospf 7 }

  ospfIfEntry OBJECT-TYPE
   SYNTAX  

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

[Ketan Talaulikar (ketant)]

I support the WG adoption of this document. It covers an important piece of the 
FlexAlgorith solution space.

Thanks,
Ketan

From: Lsr  On Behalf Of Acee Lindem (acee)
Sent: 02 December 2020 02:43
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] [Idr] WG Adoption for draft-zhu-idr-bgp-ls-path-mtu (11/1/2020 to 11/16/2020)

[Ketan Talaulikar (ketant)]

Hi Sue,

I was referring to 
https://datatracker.ietf.org/doc/draft-ketant-idr-bgp-ls-bgp-only-fabric/

Seeing the interest in the WG to progress BGP-LS advertisements in BGP-only 
networks, I would request for the WG to consider adoption of the above draft. I 
believe the problem statement of the draft is clear and acknowledge that it 
needs updates. So I will leave it to the chairs’ judgement if it is in a good 
enough state for adoption 

Thanks,
Ketan

From: Susan Hares 
Sent: 16 November 2020 11:40
To: 'Jeff Tantsura' ; Les Ginsberg (ginsberg) 

Cc: Ketan Talaulikar (ketant) ; Stephane Litkowski (slitkows) 
; i...@ietf.org; Acee Lindem (acee) ; 
lsr@ietf.org
Subject: RE: [Idr] WG Adoption for draft-zhu-idr-bgp-ls-path-mtu (11/1/2020 to 
11/16/2020)

Jeff:

I agree your BGP-LS only deployment in the MSD document were not well defined.

Starting a new set of work to define BGP-LS use in BGP-only is important.  If 
this document start the process to refine how BGP-only works, this will help 
defined this usage.   I stand by the agreement that the BGP-LS that exposes the 
OSPF/ISIS Link MTU proposal can be adopted in LSR.  However, this discussion 
has confirmed that the BGP-LS support for BGP-only needs some BGP focus.

If there are other drafts on this topic, it would be good to suggest this 
drafts on the list.   Ketan suggested he had one.

Cheers, Sue


From: Jeff Tantsura [mailto:jefftant.i...@gmail.com]
Sent: Friday, November 13, 2020 8:52 PM
To: Les Ginsberg (ginsberg)
Cc: Ketan Talaulikar (ketant); Susan Hares; Stephane Litkowski (slitkows); 
i...@ietf.org<mailto:i...@ietf.org>; Acee Lindem (acee); 
lsr@ietf.org<mailto:lsr@ietf.org>
Subject: Re: [Idr] WG Adoption for draft-zhu-idr-bgp-ls-path-mtu (11/1/2020 to 
11/16/2020)

To add to Les’s point of BGP only scenario, during MSD IESG reviews, BGP-LS 
only deployment was found not well characterized and had been removed from the 
draft. It will require much better discussion to have it included.
Regards,
Jeff

On Nov 13, 2020, at 15:57, Les Ginsberg (ginsberg) 
mailto:ginsb...@cisco.com>> wrote:

The points which Ketan has made regarding the use of MTU advertisements defined 
in RFC 7176 are very valid. Indeed, the contents of the sub-TLV defined in 
https://www.rfc-editor.org/rfc/rfc7176.html#section-2.4 depend upon the TRILL 
specific MTU-probe/MTU-ack procedures defined in 
https://www.rfc-editor.org/rfc/rfc6325#section-4.4.3. These procedures are not 
currently applicable to non-TRILL environments.

So, there are no existing IGP advertisements defined which can support the 
goals of this draft.

As Ketan has also indicated, there is no discussion in the draft of how a BGP 
only network (for example) could provide the information of interest.

From my perspective, WG adoption of this draft in ANY WG is premature.
This might be a useful functionality to have – but at the moment we simply have 
an idea with no definition of how to implement/deploy it.

So I therefore oppose WG adoption of this draft by IDR.

Continuing the discussion is certainly useful – and I would encourage the 
current authors to investigate and propose relevant mechanisms in all the 
protocols of interest in some future version of the draft.
At that point we could then have a far more meaningful WG adoption call.

   Les


From: Idr mailto:idr-boun...@ietf.org>> On Behalf Of 
Ketan Talaulikar (ketant)
Sent: Friday, November 13, 2020 1:35 AM
To: Susan Hares mailto:sha...@ndzh.com>>; 'Jeff Tantsura' 
mailto:jefftant.i...@gmail.com>>; 'Stephane Litkowski 
(slitkows)' 
mailto:slitkows=40cisco@dmarc.ietf.org>>;
 i...@ietf.org<mailto:i...@ietf.org>; 'Acee Lindem (acee)' 
mailto:acee=40cisco@dmarc.ietf.org>>
Cc: lsr@ietf.org<mailto:lsr@ietf.org>
Subject: Re: [Idr] WG Adoption for draft-zhu-idr-bgp-ls-path-mtu (11/1/2020 to 
11/16/2020)

Hi Authors,

I believe this work is useful and should be taken up. It has value in providing 
the link MTU as part of the topology information via BGP-LS. However, as 
pointed out by others on this thread, the draft should remain scoped to just 
that – i.e. providing link MTU information. The discussion related to Path MTU 
and applicability to SR networks are best left outside the scope of this 
standards track draft.

Hi Sue,

I would support the points made by Acee for not taking up this draft in IDR WG 
and instead doing this in LSR.

Besides the missing coverage for OSPFv2/v3, there are also issues with how this 
would work with ISIS. The reference to the ISIS Trill specification points to 
this TLV https://tools.ietf.org/html/rfc7176#section-2.4 – if you see, there is 
more here than just the MTU value. What is more critical is the ISIS procedures 
(in non-Trill deployments) on how this value is determined. Please do not mix 
the following :

The MTU sub-TLV is used to optionally announce the MTU of a link as
   specified in [RFC6325], Section 
4.2.4.4<https://tools.

Re: [Lsr] [Idr] WG Adoption for draft-zhu-idr-bgp-ls-path-mtu (11/1/2020 to 11/16/2020)

[Ketan Talaulikar (ketant)]

Hi Zhibo,

I agree with everything that was discussed and concluded on that thread which 
you referred to.

It was about re-using existing sub-TLV for link MTU defined for Trill in ISIS. 
We are still saying the same thing! There is still the work required for the 
base ISIS procedures to be defined for the same.

Note that I did ask about the ISIS procedures for MTU during the last IETF 
online where the draft was presented. I was referred to the Trill spec at that 
time. But as we can clearly see those procedures are not applicable for normal 
ISIS.

Perhaps there was a misunderstanding somewhere in the middle that resulted in 
the approach that the authors took (i.e. assuming everything else was done and 
only BGP-LS remained) ?

In the thread the authors also spoke about OSPF but that seemed to have been 
dropped. As mentioned in my feedback, I am happy to help with if required.

Finally, I don’t see any opposition to the work itself or for it to be adopted 
(in due course). The discussion is on the “missing pieces” for this proposal to 
work and where this work is better accomplished.

Thanks,
Ketan

From: Huzhibo 
Sent: 14 November 2020 08:50
To: Les Ginsberg (ginsberg) ; Ketan Talaulikar (ketant) 
; Susan Hares ; 'Jeff Tantsura' 
; Stephane Litkowski (slitkows) ; 
i...@ietf.org; Acee Lindem (acee) 
Cc: lsr@ietf.org
Subject: 答复: [Idr] WG Adoption for draft-zhu-idr-bgp-ls-path-mtu (11/1/2020 to 
11/16/2020)

Hi Les, Acee:

Actually we have already discussed about this and reached agreements about two 
years ago. You may have forgotten. Please find the archives below.

https://mailarchive.ietf.org/arch/msg/lsr/C2bhd2ff2UJf4e_Gr-7j2W0g-SU/

I have followed your advice: "there already is a per link MTU sub-TLV defined 
by RFC 7176 ... in which case the existing sub-TLV is a perfect fit ...  IS-IS 
already has what is needed and therefore does not need any additional protocol 
extension". So we let our draft on ISIS extensions for MTU expired, i.e. 
draft-hu-lsr-isis-path-mtu. To be honest, I am a bit surprised when I saw your 
comments.

In this draft we focused on the extensions of BGP_LS for MTU only, which does 
not have to be feed by IGP LSDB. This draft has been discussed and revised a 
few rounds, based on the feedbacks both on ietf meetings and mail list, this 
document has good maturity to move forward.

Thanks
Zhibo


发件人: Idr [mailto:idr-boun...@ietf.org] 代表 Les Ginsberg (ginsberg)
发送时间: 2020年11月14日 7:58
收件人: Ketan Talaulikar (ketant) 
mailto:ketant=40cisco@dmarc.ietf.org>>; 
Susan Hares mailto:sha...@ndzh.com>>; 'Jeff Tantsura' 
mailto:jefftant.i...@gmail.com>>; 'Stephane Litkowski 
(slitkows)' 
mailto:slitkows=40cisco@dmarc.ietf.org>>;
 i...@ietf.org<mailto:i...@ietf.org>; 'Acee Lindem (acee)' 
mailto:acee=40cisco@dmarc.ietf.org>>
抄送: lsr@ietf.org<mailto:lsr@ietf.org>
主题: Re: [Idr] WG Adoption for draft-zhu-idr-bgp-ls-path-mtu (11/1/2020 to 
11/16/2020)

The points which Ketan has made regarding the use of MTU advertisements defined 
in RFC 7176 are very valid. Indeed, the contents of the sub-TLV defined in 
https://www.rfc-editor.org/rfc/rfc7176.html#section-2.4 depend upon the TRILL 
specific MTU-probe/MTU-ack procedures defined in 
https://www.rfc-editor.org/rfc/rfc6325#section-4.4.3. These procedures are not 
currently applicable to non-TRILL environments.

So, there are no existing IGP advertisements defined which can support the 
goals of this draft.

As Ketan has also indicated, there is no discussion in the draft of how a BGP 
only network (for example) could provide the information of interest.

From my perspective, WG adoption of this draft in ANY WG is premature.
This might be a useful functionality to have – but at the moment we simply have 
an idea with no definition of how to implement/deploy it.

So I therefore oppose WG adoption of this draft by IDR.

Continuing the discussion is certainly useful – and I would encourage the 
current authors to investigate and propose relevant mechanisms in all the 
protocols of interest in some future version of the draft.
At that point we could then have a far more meaningful WG adoption call.

   Les


From: Idr mailto:idr-boun...@ietf.org>> On Behalf Of 
Ketan Talaulikar (ketant)
Sent: Friday, November 13, 2020 1:35 AM
To: Susan Hares mailto:sha...@ndzh.com>>; 'Jeff Tantsura' 
mailto:jefftant.i...@gmail.com>>; 'Stephane Litkowski 
(slitkows)' 
mailto:slitkows=40cisco@dmarc.ietf.org>>;
 i...@ietf.org<mailto:i...@ietf.org>; 'Acee Lindem (acee)' 
mailto:acee=40cisco@dmarc.ietf.org>>
Cc: lsr@ietf.org<mailto:lsr@ietf.org>
Subject: Re: [Idr] WG Adoption for draft-zhu-idr-bgp-ls-path-mtu (11/1/2020 to 
11/16/2020)

Hi Authors,

I believe this work is useful and should be taken up. It has value in providing 
the link MTU as part of the topology information via BGP-LS. However, as 
pointed out by others on this thread, the draft sh

Re: [Lsr] [Idr] WG Adoption for draft-zhu-idr-bgp-ls-path-mtu (11/1/2020 to 11/16/2020)

[Ketan Talaulikar (ketant)]

Hi Authors,

I believe this work is useful and should be taken up. It has value in providing 
the link MTU as part of the topology information via BGP-LS. However, as 
pointed out by others on this thread, the draft should remain scoped to just 
that – i.e. providing link MTU information. The discussion related to Path MTU 
and applicability to SR networks are best left outside the scope of this 
standards track draft.

Hi Sue,

I would support the points made by Acee for not taking up this draft in IDR WG 
and instead doing this in LSR.

Besides the missing coverage for OSPFv2/v3, there are also issues with how this 
would work with ISIS. The reference to the ISIS Trill specification points to 
this TLV https://tools.ietf.org/html/rfc7176#section-2.4 – if you see, there is 
more here than just the MTU value. What is more critical is the ISIS procedures 
(in non-Trill deployments) on how this value is determined. Please do not mix 
the following :

The MTU sub-TLV is used to optionally announce the MTU of a link as
   specified in [RFC6325], Section 
4.2.4.4.

Are the authors trying to specify that these Trill procedures for testing MTU 
need to be adopted for regular ISIS deployments.

My take is that while the ISIS TLV defined for Trill may be re-used in normal 
ISIS deployments, its usage and procedures need to be specified. Copying the 
LSR WG so that I may be corrected if I am wrong here.

Coming to the point of BGP-only networks, the draft has zero text related to 
that scenario. Moreover, the procedures for BGP-LS advertisements in BGP only 
fabric need to be specified as a base. The 
https://datatracker.ietf.org/doc/draft-ketant-idr-bgp-ls-bgp-only-fabric/ was 
my attempt to specify those procedures and it would be great if the IDR WG 
could review and provide feedback to this document and consider for adoption so 
we can cover the BGP-only networks.

I would also like to offer support/help to the authors in adding the necessary 
OSPFv2/v3 support for the same in an LSR draft where we could tackle both the 
IGPs and BGP-LS encoding and procedures together.

Thanks,
Ketan

From: Idr  On Behalf Of Susan Hares
Sent: 13 November 2020 00:20
To: 'Jeff Tantsura' ; 'Stephane Litkowski (slitkows)' 
; i...@ietf.org; 'Acee Lindem (acee)' 

Subject: Re: [Idr] WG Adoption for draft-zhu-idr-bgp-ls-path-mtu (11/1/2020 to 
11/16/2020)

Jeff and Authors of draft-zhu-idr-bgp-ls-path-mtu:

I do believe the authors agreed to renaming the draft.

Does the name:   draft-xxx-idr-bgp-ls-link-mtu work for
the authors and interested IDR participants.

As the end of 12 days of the 14 day WG LC, this draft appears
to have general consensus from the WG as a useful draft.

I plan to allow 2 more days of comment, but at this point
it appears the WG wishes to adopt this draft.

Here’s my understanding of the best way forward:

If LSR adopts a version of the draft, IDR will allow the
LSR WG to be the main source as long as cross-working
review occurs so the BGP-only function can be reviewed.

Please continue to comment on the draft and
the planned progression.

Cheers,  Sue

From: Jeff Tantsura [mailto:jefftant.i...@gmail.com]
Sent: Thursday, November 12, 2020 12:53 PM
To: Susan Hares; Stephane Litkowski (slitkows); 
i...@ietf.org; Acee Lindem (acee)
Subject: Re: [Idr] WG Adoption for draft-zhu-idr-bgp-ls-path-mtu (11/1/2020 to 
11/16/2020)

+1 to everything Acee said

Cheers,
Jeff
On Nov 10, 2020, 1:01 PM -0800, Acee Lindem (acee) 
mailto:acee=40cisco@dmarc.ietf.org>>, 
wrote:
Speaking as an IDR WG member:

The name of the draft is wrong – the extension is for a Link MTU and not a path 
MTU.

Speaking as LSR Chair:

We could this in LSR as there is currently no MTU advertisement in the LSAs for 
OSPFv2 and OSPFv3. Implementations already make use of this information as it 
is used in the OSPF DBD packets and for LSA packing. Of course, we’d require a 
more accurate draft name and title.

Thanks,
Acee

From: Idr mailto:idr-boun...@ietf.org>> on behalf of 
Susan Hares mailto:sha...@ndzh.com>>
Date: Monday, November 9, 2020 at 4:20 PM
To: "'Stephane Litkowski (slitkows)'" 
mailto:slitkows=40cisco@dmarc.ietf.org>>,
 IDR List mailto:i...@ietf.org>>
Subject: Re: [Idr] WG Adoption for draft-zhu-idr-bgp-ls-path-mtu (11/1/2020 to 
11/16/2020)

Stephane:

My second message to this thread asked a few questions about the technology.

This information can be more than IGP information.   If SR segments statically 
defined (static or direct interfaces) tunnels and pass the endpoints via BGP 
tunnel-encaps draft with SR Policy tunnel type, this can just be BGP.

I’ll keep this WG adoption call going until we can be sure if:  1) it something 
LSR wants to standardize, and 2) whether there is a BGP only case.   It is 
clear to me that standardizing MTU for a SR segments with stacked tunnel 
segments passed by BGP was useful.

The authors should be the ones to 

Re: [Lsr] WG adoption call for draft-ketant-lsr-ospf-l2bundles-01

[Ketan Talaulikar (ketant)]

Hi Chris,

Thanks for the update and we've just posted 
https://tools.ietf.org/html/draft-ietf-lsr-ospf-l2bundles-00

Thanks,
Ketan

-Original Message-
From: Christian Hopps  
Sent: 29 October 2020 23:57
To: lsr@ietf.org
Cc: Christian Hopps ; lsr-cha...@ietf.org; 
draft-ketant-lsr-ospf-l2bundles@ietf.org
Subject: Re: [Lsr] WG adoption call for draft-ketant-lsr-ospf-l2bundles-01

The document is adopted.

Authors, please resubmit as draft-ietf-lsr-ospf-l2bundles-00

Thanks,
Chris.

> On Oct 2, 2020, at 8:03 AM, Christian Hopps  wrote:
> 
> Signed PGP part
> This begins a 2 week WG adoption call for the following draft:
> 
>  https://datatracker.ietf.org/doc/draft-ketant-lsr-ospf-l2bundles/
> 
> Please indicate your support or objection by October 16, 2020.
> 
> Authors, please respond to the list indicating whether you are aware of any 
> IPR that applies to this draft.
> 
> Thanks,
> Chris and Acee.
> 
> 

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

Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06

[Ketan Talaulikar (ketant)]

Hi Chris/All,

We've just posted the v07 of the draft with the contentious appendix sections 
removed and also addressing some comments received on the list.

https://tools.ietf.org/html/draft-ietf-lsr-ospf-prefix-originator-07 

Thanks,
Ketan (on behalf on co-authors)

-Original Message-
From: Lsr  On Behalf Of Christian Hopps
Sent: 19 October 2020 22:37
To: Aijun Wang 
Cc: Les Ginsberg (ginsberg) ; John E Drake 
; Christian Hopps ; lsr-cha...@ietf.org; 
lsr@ietf.org; Jeff Tantsura ; 
draft-ietf-lsr-ospf-prefix-origina...@ietf.org; lsr-...@ietf.org
Subject: Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06



> On Oct 16, 2020, at 4:47 AM, Aijun Wang  wrote:
> 
> Hi, Les and experts in LSR:
> 
> I am open to the removal of the this appendix to forward this draft.

That's good news, thank you Aijun.

Speaking for the chairs,

We believe we have reached WG consensus (seems better than just rough even with 
some authors asking for the change) at this point on the removal of the 
disputed use-case appendices.

Could you please republish the document w/o the disputed sections?

Thanks,
Chris.

> But as stated in previous mail, providing this can assist the user/reader of 
> the draft. We often encounter the questions in the mail list that what the 
> usage of protocol/bit definition in some drafts.
> 
> Actually, we did not expand the discussion of this part in this draft. The 
> description of this part is very concise.
> 
> If you insist this, I can update the draft in recent days, together with 
> other comments on this draft.
> 
> Other comments are welcome also!
> 
> Aijun Wang
> China Telecom
> 
>> On Oct 16, 2020, at 13:51, Les Ginsberg (ginsberg)  
>> wrote:
>> 
>> Aijun -
>> 
>> The point I am making is very focused.
>> 
>> This draft is defining a protocol extension. As such it is necessary that 
>> this be Standards track as adhering to the normative statements in the draft 
>> are necessary for interoperability.
>> 
>> What is discussed in the Appendix is a use case. It is not normative and 
>> there are strong opinions on both sides as to whether this is an appropriate 
>> use case or not.
>> In the context of this draft, I have no interest in trying to resolve our 
>> difference of opinion on this use case. I simply want the protocol extension 
>> to move forward so that we have another tool available.
>> 
>> If you want to write a draft on the use case discussed in the Appendix 
>> please feel free to do so. That draft may very well not be normative - 
>> Informational or BCP may be more appropriate - because it will be discussing 
>> a deployment scenario and a proposal to use defined protocol extensions as 
>> one way to solve problems in that deployment scenario. Such a draft might 
>> also be more appropriate in another WG (e.g., TEAS). The merits of using 
>> prefix advertisements to build a topology could then be discussed on its own.
>> 
>> Please do not try to avoid having a full discussion of the merits of using 
>> prefix advertisements to derive topology by adding it to a draft that is 
>> (and should be) focused on simple protocol extensions.
>> 
>> Thanx.
>> 
>>  Les
>> 
>> 
>>> -Original Message-
>>> From: Aijun Wang 
>>> Sent: Thursday, October 15, 2020 6:51 PM
>>> To: 'Jeff Tantsura' ; 'John E Drake'
>>> 
>>> Cc: 'Christian Hopps' ; lsr-cha...@ietf.org; Les 
>>> Ginsberg
>>> (ginsberg) ; lsr@ietf.org; lsr-...@ietf.org; 
>>> draft-ietf- lsr-ospf-prefix-origina...@ietf.org
>>> Subject: RE: [Lsr] WG Last Call 
>>> draft-ietf-lsr-ospf-prefix-originator-06
>>> 
>>> Hi, Les, John and Jeff:
>>> 
>>> Let's reply you all together.
>>> In my POV, The standard document should not define solely the 
>>> protocol extension, but their usages in the network deployment. As I 
>>> known, almost all the IETF documents following this style.
>>> And, before adopting one work, we have often intense discussion for 
>>> what's their usages.
>>> Such discussion in the mail list and statements in the doc
> 

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

Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06

[Ketan Talaulikar (ketant)]

Hi Baalajee,

Thanks for you review and comments. We’ll incorporate these 
fixes/clarifications in the upcoming update.

Thanks,
Ketan

From: Baalajee S (basurend) 
Sent: 20 October 2020 10:48
To: Christian Hopps ; lsr@ietf.org
Cc: draft-ietf-lsr-ospf-prefix-origina...@ietf.org; lsr-cha...@ietf.org; 
lsr-...@ietf.org
Subject: Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06


Hello authors,



I have a couple of comments.



1.
   A received Prefix Originator Sub-TLV that has an invalid length (not
   4 or 16) or a Reachable Address containing an invalid IPv4 or IPv6
   address (dependent on address family of the associated prefix) MUST
   be considered invalid and ignored.  Additionally, reception of such
   Sub-TLV SHOULD be logged as an error (subject to rate-limiting).


Shouldn’t that be “Router address”?


2.
   If the originating node is advertising an OSPFv2 Router Address TLV
   [RFC3630] or an OSPFv3 Router IPv6 
Address TLV [RFC5329], then that
   value is set in the Router Address field of the Prefix Originator
   Sub-TLV.  When the orignating node is not advertising such an



Wang, et al. Expires January 1, 2021[Page 5]


Internet-Draft  OSPF Prefix Originator Extensions  June 2020


   address, implementations MAY support mechanisms to determine a
   reachable address belonging to the originating node to set in the
   Router Address field.  Such mechanisms are outside the scope of this
   document.


Originating -> originating



I assume that the “Router address” picked by a router could be one of the 
addresses advertised by it with “N-bit” (Node SID) set or some other reachable 
address which uniquely identifies the router.



Regards,

S. Baalajee



On 15/10/20, 11:46 AM, "Lsr on behalf of Christian Hopps" 
mailto:lsr-boun...@ietf.org%20on%20behalf%20of%20cho...@chopps.org>>
 wrote:



This begins a 2 week WG Last Call, ending after Oct 29th, 2020, for:



  https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-prefix-originator/



The following IPR has been filed https://datatracker.ietf.org/ipr/3448/



Authors,



  Please indicate to the list, your knowledge of any other IPR related to 
this work.



Thanks,

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

Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06

[Ketan Talaulikar (ketant)]

Hi Gyan,

Thanks for your review and feedback. Please check inline below.

From: Gyan Mishra 
Sent: 16 October 2020 10:11
To: Aijun Wang 
Cc: Christian Hopps ; Jeff Tantsura 
; John E Drake ; 
Les Ginsberg (ginsberg) ; 
draft-ietf-lsr-ospf-prefix-origina...@ietf.org; lsr@ietf.org; lsr-...@ietf.org; 
lsr-cha...@ietf.org
Subject: Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06

I support advancement of the draft.

This draft follows along the lines of ISIS RFC 7794 to provide an extension to 
identify the prefix originator attribute using an originating router TLV and a 
reachable prefix.  A node in ospf is represented by a router-id which 
technically can be a random 4 octet prefix that does not have to be reachable 
entry in the IGP RIB.

The reachability prefix is important in cases where the originator router-id is 
not  in the RIB or in traffic engineering inter as path instantiation use case 
where the router-id originator node is advertised, however since the TEDs 
database link attributes are not known inter-as,having the reachability address 
is important as defined in the draft.  This feature can also be used  
identifying the prefix originator in a normal user case other then the traffic 
engineering scenario such as for troubleshooting which is common to view all 
the prefixes advertised by a node by Prefix type.

There maybe cases where you need to create  a database filter or policy and if 
you can use this feature as a means of controlling prefix advertisements based 
on source node that can be powerful and could have ubiquitous use cases.

With regards to the appendix it does appear to be pertinent, as the use case 
appears to be the primary focal point and reason for the draft by the authors.  
I don’t think that having the appendix  precluding other use cases by any means.
[KT] The Introduction section of the draft does touch upon some of the primary 
use-cases that authors believe have more wide-spread applicability. You have 
also alluded to some of them and then you have also brought out some newer 
use-cases/applications of the extensions in this draft. There were other 
use-cases in previous versions like ELC which later went away based on how we 
addressed that in draft-ietf-ospf/isis-mpls-elc documents. I am sure there will 
be newer use-cases. The focus of the draft is primary to capture the protocol 
extensions since that is what we work on in LSR. The scope of the use-cases may 
be beyond LSR and in other areas (e.g. TEAS perhaps for the one in the appendix 
?). Regarding the use-case in the appendix, it would be fair to say that it was 
primary focal point for some of the authors.

I will leave it to the WG consensus on what content we should be sending to the 
IESG.

Thanks,
Ketan

Kind Regards

Gyan

On Thu, Oct 15, 2020 at 9:51 PM Aijun Wang 
mailto:wangai...@tsinghua.org.cn>> wrote:
Hi, Les, John and Jeff:

Let's reply you all together.
In my POV, The standard document should not define solely the protocol 
extension, but their usages in the network deployment. As I known, almost all 
the IETF documents following this style.
And, before adopting one work, we have often intense discussion for what's 
their usages.
Such discussion in the mail list and statements in the document can certainly 
assist the reader/user of the document get the essence of the standard, and 
follow them unambiguously.

Regarding the contents of appendices, as stated in the section, "The Appendix A 
heuristic to rebuild the topology can normally be used if all links are 
numbered." I think this can apply almost most of the operator's network, and 
facilitate the inter-area TE path calculation for central controller, or even 
for the head-end router that located in one area that different from the 
tail-end router.

Keeping the contents of appendices does not have the negative impact of the 
protocol extension, it is just one reference for the usage of this extension.
One can select not refer to it, if their networks are deployed with large 
amount of unnumbered links. But for others, the heuristic applies.

Best Regards

Aijun Wang
China Telecom



-Original Message-
From: lsr-boun...@ietf.org 
[mailto:lsr-boun...@ietf.org] On Behalf Of Jeff 
Tantsura
Sent: Friday, October 16, 2020 5:28 AM
To: John E Drake 
mailto:40juniper@dmarc.ietf.org>>
Cc: Christian Hopps mailto:cho...@chopps.org>>; 
lsr-cha...@ietf.org; Les Ginsberg (ginsberg) 
mailto:40cisco@dmarc.ietf.org>>; 
lsr@ietf.org; lsr-...@ietf.org; 
draft-ietf-lsr-ospf-prefix-origina...@ietf.org
Subject: Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06

+1

Regards,
Jeff

> On Oct 15, 2020, at 11:33, John E Drake 
> mailto:40juniper@dmarc.ietf.org>> 
> wrote:
>
> Hi,
>
> I agree with Les.  This is a simple protocol 

Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06

[Ketan Talaulikar (ketant)]

Hello,

I support the progression to publication and as co-author, I am not aware of 
any undisclosed IPR.

Thanks,
Ketan

-Original Message-
From: Christian Hopps  
Sent: 15 October 2020 11:45
To: lsr@ietf.org
Cc: Christian Hopps ; lsr-cha...@ietf.org; lsr-...@ietf.org; 
draft-ietf-lsr-ospf-prefix-origina...@ietf.org
Subject: WG Last Call draft-ietf-lsr-ospf-prefix-originator-06

This begins a 2 week WG Last Call, ending after Oct 29th, 2020, for:

  https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-prefix-originator/

The following IPR has been filed https://datatracker.ietf.org/ipr/3448/

Authors,

  Please indicate to the list, your knowledge of any other IPR related to this 
work.

Thanks,
Chris.

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

Re: [Lsr] WG adoption call for draft-ketant-lsr-ospf-l2bundles-01

[Ketan Talaulikar (ketant)]

Hi Gyan,

Thanks for your support and comments on the draft.

The proposed encoding for L2 Bundle members and their attributes in OSPF is 
different than the ISIS encodings in RFC8668. ISIS encodings have “tighter” LSP 
space considerations that OSPF. The authors have proposed a simpler encoding 
scheme for OSPF – feedback/inputs are welcome.

The list of attributes in Figure 2 and 3 also includes L2 Bundle member Adj 
SID. Since the encoding scheme is similar to Layer 3 attributes, we can re-use 
the same sub-TLVs.

Thanks,
Ketan

From: Lsr  On Behalf Of Gyan Mishra
Sent: 03 October 2020 04:07
To: Les Ginsberg (ginsberg) 
Cc: lsr@ietf.org; draft-ketant-lsr-ospf-l2bundles@ietf.org; Christian Hopps 
; lsr-cha...@ietf.org
Subject: Re: [Lsr] WG adoption call for draft-ketant-lsr-ospf-l2bundles-01


I support WG adoption of this draft.

I agree that OSPF needs the functionality equivalent to that defined for IS-IS 
in RFC 8668.

I think the draft should include similar to RFC 8668 section 3 parallel layer 3 
adjacencies 3 similar Sub TLVs mentioned flag for multiple parallel adjacencies.

Also maybe section 4 of RFC 8668 would apply as well to ospf advertisement of 
L2 bundle Adj sid.

Thanks

Gyan

On Fri, Oct 2, 2020 at 6:11 PM Les Ginsberg (ginsberg) 
mailto:40cisco@dmarc.ietf.org>> wrote:
I support WG adoption of this draft.

OSPF needs functionality equivalent to that defined for IS-IS in RFC 8668.



   Les





> -Original Message-

> From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of 
> Christian Hopps

> Sent: Friday, October 02, 2020 5:03 AM

> To: lsr@ietf.org

> Cc: lsr-cha...@ietf.org; Christian Hopps 
> mailto:cho...@chopps.org>>; draft-ketant-

> lsr-ospf-l2bundles@ietf.org

> Subject: [Lsr] WG adoption call for draft-ketant-lsr-ospf-l2bundles-01

>

> This begins a 2 week WG adoption call for the following draft:

>

>   https://datatracker.ietf.org/doc/draft-ketant-lsr-ospf-l2bundles/

>

> Please indicate your support or objection by October 16, 2020.

>

> Authors, please respond to the list indicating whether you are aware of any

> IPR that applies to this draft.

>

> Thanks,

> Chris and Acee.



___

Lsr mailing list

Lsr@ietf.org

https://www.ietf.org/mailman/listinfo/lsr
--

[http://ss7.vzw.com/is/image/VerizonWireless/vz-logo-email]

Gyan Mishra

Network Solutions Architect

M 301 502-1347
13101 Columbia Pike
Silver Spring, MD

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

Re: [Lsr] WG adoption call for draft-ketant-lsr-ospf-l2bundles-01

[Ketan Talaulikar (ketant)]

I support the adoption of this document by the WG and as an author, I am not 
aware of any IPR associated with it.

Thanks,
Ketan

-Original Message-
From: Christian Hopps  
Sent: 02 October 2020 17:33
To: lsr@ietf.org
Cc: Christian Hopps ; lsr-cha...@ietf.org; 
draft-ketant-lsr-ospf-l2bundles@ietf.org
Subject: WG adoption call for draft-ketant-lsr-ospf-l2bundles-01

This begins a 2 week WG adoption call for the following draft:

  https://datatracker.ietf.org/doc/draft-ketant-lsr-ospf-l2bundles/

Please indicate your support or objection by October 16, 2020.

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

Thanks,
Chris and Acee.

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

Re: [Lsr] IPR Call on "IGP Flexible Algorithm" - draft-ietf-lsr-flex-algo-11.txt

[Ketan Talaulikar (ketant)]

I am not aware of any IPR other than the one already disclosed below.

Thanks,
Ketan

From: Acee Lindem (acee) 
Sent: 02 October 2020 01:54
To: draft-ietf-lsr-flex-a...@ietf.org
Cc: lsr@ietf.org
Subject: IPR Call on "IGP Flexible Algorithm" - draft-ietf-lsr-flex-algo-11.txt

Authors,

The following IPR has been disclosed (excerpted from 
https://datatracker.ietf.org/ipr/search/?submit=draft=draft-ietf-lsr-flex-algo):

Date
ID
Statement
2018-08-08
3248
Cisco's Statement about IPR related to 
draft-ietf-lsr-flex-algo
2019-12-05
3910
Huawei Technologies Co.,Ltd's Statement about IPR related to 
draft-ietf-lsr-flex-algo


Are you aware of any other IPR that applies to draft-ietf-lsr-flex-algo?

If so, has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs 3979, 4879, 3669 and 5378 for more details).

If you are listed as a document author or contributor please respond
to this email regardless of whether or not you are aware of any
relevant IPR. *The response needs to be sent to the LSR WG mailing
list.* The document will not advance to the next stage until a
response has been received from each author and contributor.

If you are on the LSR WG email list but are not listed as an author or
contributor, then please explicitly respond only if you are aware of
any IPR that has not yet been disclosed in conformance with IETF rules.

Thanks,
Acee


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

Re: [Lsr] I-D Action: draft-ietf-lsr-isis-srv6-extensions-10.txt

[Ketan Talaulikar (ketant)]

Hi Joel,

Please check inline below.

-Original Message-
From: Lsr  On Behalf Of Joel M. Halpern
Sent: 25 September 2020 19:08
To: Ketan Talaulikar (ketant) ; lsr@ietf.org
Subject: Re: [Lsr] I-D Action: draft-ietf-lsr-isis-srv6-extensions-10.txt

Thanks Ketan.  Let me paraphrase to confirm I understand, with some 
suggestions.  And repeat the last question which seems to have gotten lost.

It seems that you are saying that the arg field is defined for now so the 
format is consistent, but is not used by any behavior defined in this draft.
[KT] The ISIS draft does not actually define any behavior - it only specifies 
signaling of a subset of behaviors defined in net-pgm. You are right that the 
behaviors that are listed as being signalled by ISIS in the current document do 
not support an ARG.

If so, should we say explicitly that ARG is (or MUST be) 0 for all the 
behaviors defined in this draft?
[KT] I am not sure it is necessary. A future ISIS extension may introduce 
support for signaling of a behavior that supports ARG.

Then separately the folks working on the END.DT2M behavior can write their own 
draft one how to advertise that in is-is?  Presumably with an additional 
sub-TLV dealing with k and x?
[KT] End.DT2M is signaled in BGP and specified in BGP extensions. If a future 
ISIS extension was to advertise a SID with a behavior supporting ARG, then it 
would need to clarify its handling of the ARG.

Also, can you tell me how the association of an END.T behavior with a table is 
understood from the advertisement as described in the draft?
[KT] Indeed, the End.T signaling does not carry the table context with it. 

Thanks,
Ketan

Thank you,
Joel

On 9/25/2020 1:39 AM, Ketan Talaulikar (ketant) wrote:
> Hi Joel,
> 
> Please check inline below.
> 
> -Original Message-
> From: Lsr  On Behalf Of Joel M. Halpern
> Sent: 25 September 2020 03:18
> To: Acee Lindem (acee) ; lsr@ietf.org
> Subject: Re: [Lsr] I-D Action: 
> draft-ietf-lsr-isis-srv6-extensions-10.txt
> 
> First, there is a slight confusion in the way I formed the quesiton, but I 
> think it still applies.
> 
> The piece of this draft is section 9, which advertises the length of the arg 
> portion of the SID.  But does not provide specific meanings for specific 
> values.
> [KT] This is quite appropriate for this draft since it is only specifying a 
> generic SID structure and not associated with any specific behavior.
> 
> The example of an ARG in the network programming draft does provide part of 
> the explicit interpretation of the ARG.  It says that it is a list of k 
> items, each of x bits, where each x bit blob identifies an OIF.
> [KT] The net-pgm draft in sec 4.12 introduces a specific End.DT2M behavior 
> which includes support for ARG. That said, I am not quite sure about that 
> text in that section which talks about how the ARG bits are formed and what 
> they signify. I believe the ARG in this case is a locally assigned identifier 
> that maps to an ESI so that it can be used for ESI filtering - much the same 
> as an ESI label for split-horizon filtering. I see a comment from one of the 
> ADs on this and I expect that the authors will clarify.
> 
> This leaves two gaps, and a more general question.
> 1) How does the receiver know the meanings of the OIF indices so that he can 
> correctly fill them in?
> 2) The NP draft says that k and x are defined on a per SID basis.  But I do 
> not see anywhere in the isis draft to advertise the values of k and x, only 
> arg (which is k*x).
> [KT] I hope the previous comment explains.
> 
> The more general question is, is there a requirement we can write down about 
> how receivers will be able to understand ARG fields in general?
> One can argue that it would belong in the network programming draft; I would 
> prefer not to delay that with a significant technical addition.
> [KT] I don't believe the handling of ARG is something that can be 
> generalized. It has to be something specific to the behavior that it is 
> associated with. Therefore, each behavior that supports an ARG needs to 
> specify its handling. The net-pgm draft is doing it for End.DT2M and future 
> documents that introduce other behaviors requiring ARG would be expected to 
> the same.
> 
> Thanks,
> Ketan
> 
> There is a related question that I came across while trying to explain this 
> question.
> 
> END.T must be associated with a forwarding table.  I presume this is done by 
> where one puts the END.T (however-many-subs) TLV.  But I can not find 
> anything in this draft that says this.  There is precisely one reference to 
> End.T in the draft.
> 
> Thank you,
> Joel
> 
> On 9/24/2020 5:25 PM, Acee Lindem (acee) wrote:
>> H Joel,
>>
>> Can you reference the specific section in t

Re: [Lsr] I-D Action: draft-ietf-lsr-isis-srv6-extensions-10.txt

[Ketan Talaulikar (ketant)]

Hi Joel,

Please check inline below.

-Original Message-
From: Lsr  On Behalf Of Joel M. Halpern
Sent: 25 September 2020 03:18
To: Acee Lindem (acee) ; lsr@ietf.org
Subject: Re: [Lsr] I-D Action: draft-ietf-lsr-isis-srv6-extensions-10.txt

First, there is a slight confusion in the way I formed the quesiton, but I 
think it still applies.

The piece of this draft is section 9, which advertises the length of the arg 
portion of the SID.  But does not provide specific meanings for specific values.
[KT] This is quite appropriate for this draft since it is only specifying a 
generic SID structure and not associated with any specific behavior.

The example of an ARG in the network programming draft does provide part of the 
explicit interpretation of the ARG.  It says that it is a list of k items, each 
of x bits, where each x bit blob identifies an OIF.
[KT] The net-pgm draft in sec 4.12 introduces a specific End.DT2M behavior 
which includes support for ARG. That said, I am not quite sure about that text 
in that section which talks about how the ARG bits are formed and what they 
signify. I believe the ARG in this case is a locally assigned identifier that 
maps to an ESI so that it can be used for ESI filtering - much the same as an 
ESI label for split-horizon filtering. I see a comment from one of the ADs on 
this and I expect that the authors will clarify.

This leaves two gaps, and a more general question.
1) How does the receiver know the meanings of the OIF indices so that he can 
correctly fill them in?
2) The NP draft says that k and x are defined on a per SID basis.  But I do not 
see anywhere in the isis draft to advertise the values of k and x, only arg 
(which is k*x).
[KT] I hope the previous comment explains.

The more general question is, is there a requirement we can write down about 
how receivers will be able to understand ARG fields in general? 
One can argue that it would belong in the network programming draft; I would 
prefer not to delay that with a significant technical addition.
[KT] I don't believe the handling of ARG is something that can be generalized. 
It has to be something specific to the behavior that it is associated with. 
Therefore, each behavior that supports an ARG needs to specify its handling. 
The net-pgm draft is doing it for End.DT2M and future documents that introduce 
other behaviors requiring ARG would be expected to the same.

Thanks,
Ketan

There is a related question that I came across while trying to explain this 
question.

END.T must be associated with a forwarding table.  I presume this is done by 
where one puts the END.T (however-many-subs) TLV.  But I can not find anything 
in this draft that says this.  There is precisely one reference to End.T in the 
draft.

Thank you,
Joel

On 9/24/2020 5:25 PM, Acee Lindem (acee) wrote:
> H Joel,
> 
> Can you reference the specific section in the IS-IS SRv6 draft you are 
> commenting on? I seem to remember this discussion but it was at least a month 
> back, if not more.
> 
> Thanks,
> Acee
> 
> On 9/23/20, 6:31 PM, "Lsr on behalf of Joel Halpern"  on behalf of j...@joelhalpern.com> wrote:
> 
>  The announcement prompted me to look again and think about an
>  interaction between this and the network programming draft.  To be
>  clear, I am NOT objecting to either this or the network programming
>  draft.  I am just wondering what I am missing.
> 
>  The NP draft, and the advertisement mechanism allows a router to
>  advertise the number of bits for the ARG portion of a SID.
> 
>  Q1: The point presumably is to avoid needing to advertise each of the
>  individual values?
> 
>  An example of this is, I think, and ARG for the table selection where
>  the ARG is the table number for the packet to be looked up in?
> 
>  Q2: If so, how does the head end know what table number corresponds to
>  what meaning?If this requires a separate advertisement there seems
>  to be no savings.  if this requires out-of-band knowledge then we seem
>  to have lost the benefit of advertising all of this in the routing 
> protocol.
> 
>  I suspect I am simply missing a piece.  can someone explain please?
> 
>  Thank you,
>  Joel
> 
>  On 9/23/2020 4:40 PM, internet-dra...@ietf.org wrote:
>  >
>  > 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   : IS-IS Extension to Support Segment Routing 
> over IPv6 Dataplane
>  >  Authors : Peter Psenak
>  >Clarence Filsfils
>  >Ahmed Bashandy
>  >Bruno Decraene
>  >Zhibo Hu
>  >Filename: draft-ietf-lsr-isis-srv6-extensions-10.txt
>  >Pages   : 25
>  >Date   

Re: [Lsr] Regarding OSPF Extended Prefix Range TLV usage for External/NSSA prefixes defined in RFC 8665

[Ketan Talaulikar (ketant)]

Hi Veerendranatha,

Please check inline below with [KT2]

-Original Message-
From: Veerendranatha Reddy V 
 
Sent: 19 August 2020 13:07
To: Ketan Talaulikar (ketant) ; Peter Psenak (ppsenak) 
; lsr@ietf.org
Subject: RE: [Lsr] Regarding OSPF Extended Prefix Range TLV usage for 
External/NSSA prefixes defined in RFC 8665

Hi Ketan,
Please find the response in line.

The IA flag in the OSPF Extended Prefix Range TLV does not indicate that the 
prefix-SID mapping advertised via it is for use for only intra or inter area 
prefixes. The mappings can be used for assignment of SIDs for ALL types of OSPF 
prefixes - regardless of the IA bit.
The IA flag is only to prevent looping during flooding of area-scoped LSAs with 
OSPF Extended Prefix Range TLVs when they are propagated across areas.

[V] As per RFC,
IA-Flag:  Inter-Area Flag.  If set, advertisement is of
   inter-area type.  An Area Border Router (ABR) that is
   advertising the OSPF Extended Prefix Range TLV between
   areas MUST set this bit.
I thought, when prefix Ranges with SID are advertised from Intra to Inter, we 
need to set this flag. So that it indicates the prefixes are of inter area 
type. Please let me know if my understanding is not correct.
[KT] What is says is "the prefix range advertisement is of type inter-area or 
intra-area" (think of it as somewhat equivalent of the D bit in ISIS when 
leaking across levels). That does not mean that the advertised mappings need to 
be used for only for intra or inter area prefixes respectively.
[V] When we receive the range TLV received at ABR, while it is originating 
opaque LSA for that range TLV across the other areas, whether it is required to 
set IA or not?
[KT2] Yes - please check the RFC8665 Sec 4 - right after where the IA flag is 
described. 

When OSPF Extended Prefix Range TLVs are advertised using AS-scope, the NSSA 
notion does not apply for them and does not restrict their flooding into or 
from NSSA areas (or stub areas for that matter).
[V] If ASBR is part of NSSA, and if we redistributed Prefix SIDs learnt form 
other protocols or other instance of OSPF, and those prefixes are result of 
Range TLV  in that protocol, we can apply range in dest  ospf instance 
[KT] I do not follow above statement - can you please try to 
elaborate/re-phrase?
[V] When redistributing  Prefix SID information to NSSA from other protocols , 
it may possible to generate Range TLV, if multiple prefixes can be aggregated 
as range., instead of generating extended Prefix TLV for each prefix. So while 
originating this range TLV, how we can differentiate whether it is intra Scope 
or NSSA scope. So that when it is received at ABR, he will consider to 
translate to inter area Opaque or External Opaque for that range.
[KT2] I believe Peter answered and clarified this part. There is no notion of 
NSSA area or NSSA-scope flooding for the Extended Prefix Range TLV. 

Thanks,
Ketan 

Thanks & Regards,
Veerendranath



-Original Message-----
From: Ketan Talaulikar (ketant) 
Sent: Wednesday, August 19, 2020 10:27 AM
To: Veerendranatha Reddy V ; Peter Psenak 
(ppsenak) ; lsr@ietf.org
Subject: RE: [Lsr] Regarding OSPF Extended Prefix Range TLV usage for 
External/NSSA prefixes defined in RFC 8665

Hi Veerendranatha,

Please check inline below.

-Original Message-
From: Veerendranatha Reddy V 

Sent: 19 August 2020 10:03
To: Ketan Talaulikar (ketant) ; Peter Psenak (ppsenak) 
; lsr@ietf.org
Subject: RE: [Lsr] Regarding OSPF Extended Prefix Range TLV usage for 
External/NSSA prefixes defined in RFC 8665

Hi Ketan,
Please find the response in line.
The IA flag in the OSPF Extended Prefix Range TLV does not indicate that the 
prefix-SID mapping advertised via it is for use for only intra or inter area 
prefixes. The mappings can be used for assignment of SIDs for ALL types of OSPF 
prefixes - regardless of the IA bit.
The IA flag is only to prevent looping during flooding of area-scoped LSAs with 
OSPF Extended Prefix Range TLVs when they are propagated across areas.

[V] As per RFC,
IA-Flag:  Inter-Area Flag.  If set, advertisement is of
   inter-area type.  An Area Border Router (ABR) that is
   advertising the OSPF Extended Prefix Range TLV between
   areas MUST set this bit.
I thought, when prefix Ranges with SID are advertised from Intra to Inter, we 
need to set this flag. So that it indicates the prefixes are of inter area 
type. Please let me know if my understanding is not correct.
[KT] What is says is "the prefix range advertisement is of type inter-area or 
intra-area" (think of it as somewhat equivalent of the D bit in ISIS when 
leaking across levels). That does not mean that the advertised mappings need to 
be used for only for intra or inter area prefixes respectively.

When OSPF Extended Prefix Range TLVs are advertised using AS-scope, the NSSA 
notion does not apply for them and does not

Re: [Lsr] Regarding OSPF Extended Prefix Range TLV usage for External/NSSA prefixes defined in RFC 8665

[Ketan Talaulikar (ketant)]

Hi Veerendranatha,

Please check inline below.

-Original Message-
From: Veerendranatha Reddy V 
 
Sent: 19 August 2020 10:03
To: Ketan Talaulikar (ketant) ; Peter Psenak (ppsenak) 
; lsr@ietf.org
Subject: RE: [Lsr] Regarding OSPF Extended Prefix Range TLV usage for 
External/NSSA prefixes defined in RFC 8665

Hi Ketan,
Please find the response in line.
The IA flag in the OSPF Extended Prefix Range TLV does not indicate that the 
prefix-SID mapping advertised via it is for use for only intra or inter area 
prefixes. The mappings can be used for assignment of SIDs for ALL types of OSPF 
prefixes - regardless of the IA bit.
The IA flag is only to prevent looping during flooding of area-scoped LSAs with 
OSPF Extended Prefix Range TLVs when they are propagated across areas.

[V] As per RFC,
IA-Flag:  Inter-Area Flag.  If set, advertisement is of
   inter-area type.  An Area Border Router (ABR) that is
   advertising the OSPF Extended Prefix Range TLV between
   areas MUST set this bit.
I thought, when prefix Ranges with SID are advertised from Intra to Inter, we 
need to set this flag. So that it indicates the prefixes are of inter area 
type. Please let me know if my understanding is not correct.
[KT] What is says is "the prefix range advertisement is of type inter-area or 
intra-area" (think of it as somewhat equivalent of the D bit in ISIS when 
leaking across levels). That does not mean that the advertised mappings need to 
be used for only for intra or inter area prefixes respectively.

When OSPF Extended Prefix Range TLVs are advertised using AS-scope, the NSSA 
notion does not apply for them and does not restrict their flooding into or 
from NSSA areas (or stub areas for that matter).
[V] If ASBR is part of NSSA, and if we redistributed Prefix SIDs learnt form 
other protocols or other instance of OSPF, and those prefixes are result of 
Range TLV  in that protocol, we can apply range in dest  ospf instance 
[KT] I do not follow above statement - can you please try to 
elaborate/re-phrase?

Thanks,
Ketan

Thanks & Regards,
Veerendranath


-Original Message-----
From: Ketan Talaulikar (ketant) 
Sent: Tuesday, August 18, 2020 11:28 PM
To: Peter Psenak ; Veerendranatha Reddy V 
; lsr@ietf.org
Subject: RE: [Lsr] Regarding OSPF Extended Prefix Range TLV usage for 
External/NSSA prefixes defined in RFC 8665

The IA flag in the OSPF Extended Prefix Range TLV does not indicate that the 
prefix-SID mapping advertised via it is for use for only intra or inter area 
prefixes. The mappings can be used for assignment of SIDs for ALL types of OSPF 
prefixes - regardless of the IA bit.

The IA flag is only to prevent looping during flooding of area-scoped LSAs with 
OSPF Extended Prefix Range TLVs when they are propagated across areas.

When OSPF Extended Prefix Range TLVs are advertised using AS-scope, the NSSA 
notion does not apply for them and does not restrict their flooding into or 
from NSSA areas (or stub areas for that matter).

I am not sure if that answers your question.

Thanks,
Ketan

-Original Message-
From: Lsr  On Behalf Of Peter Psenak
Sent: 18 August 2020 23:06
To: Veerendranatha Reddy V 
; lsr@ietf.org
Subject: Re: [Lsr] Regarding OSPF Extended Prefix Range TLV usage for 
External/NSSA prefixes defined in RFC 8665

Veerendranath,

On 18/08/2020 16:40, Veerendranatha Reddy V wrote:
> Hi Authors, All,
> 
> OSPF Extended Prefix Range TLV defined in RFC 8665 has IA flag to 
> distinguish between Intra and Inter Area scope prefixes.
> 
> Whether any restrictions to not to use Prefix Range TLV for 
> external/NSSA prefixes ?

I don't see how you can use OSPF Extended Prefix Range TLV for NSSA, the usage 
of OSPF Extended Prefix Range TLV has only been defined in the context of RFC 
8665.

thanks,
Peter


> 
> For External Prefixes, we can able to use  Prefix Range TLV  by using 
> LSA type (based on AS scope Opaque Type , so the TLV is for External
> Prefixes)
> 
> But If we need to use the Prefix Range TLV for NSSA prefixes (Type-7) 
> , which are in area scope, there is no flag/route-type field in this 
> TLV to distinguish between Intra or NSSA prefixes( as IA flag will not 
> be set anyway).
> 
> Thanks & Regards,
> 
> Veerendranath
> 

___
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] Regarding OSPF Extended Prefix Range TLV usage for External/NSSA prefixes defined in RFC 8665

[Ketan Talaulikar (ketant)]

The IA flag in the OSPF Extended Prefix Range TLV does not indicate that the 
prefix-SID mapping advertised via it is for use for only intra or inter area 
prefixes. The mappings can be used for assignment of SIDs for ALL types of OSPF 
prefixes - regardless of the IA bit.

The IA flag is only to prevent looping during flooding of area-scoped LSAs with 
OSPF Extended Prefix Range TLVs when they are propagated across areas.

When OSPF Extended Prefix Range TLVs are advertised using AS-scope, the NSSA 
notion does not apply for them and does not restrict their flooding into or 
from NSSA areas (or stub areas for that matter).

I am not sure if that answers your question.

Thanks,
Ketan

-Original Message-
From: Lsr  On Behalf Of Peter Psenak
Sent: 18 August 2020 23:06
To: Veerendranatha Reddy V 
; lsr@ietf.org
Subject: Re: [Lsr] Regarding OSPF Extended Prefix Range TLV usage for 
External/NSSA prefixes defined in RFC 8665

Veerendranath,

On 18/08/2020 16:40, Veerendranatha Reddy V wrote:
> Hi Authors, All,
> 
> OSPF Extended Prefix Range TLV defined in RFC 8665 has IA flag to 
> distinguish between Intra and Inter Area scope prefixes.
> 
> Whether any restrictions to not to use Prefix Range TLV for 
> external/NSSA prefixes ?

I don't see how you can use OSPF Extended Prefix Range TLV for NSSA, the usage 
of OSPF Extended Prefix Range TLV has only been defined in the context of RFC 
8665.

thanks,
Peter


> 
> For External Prefixes, we can able to use  Prefix Range TLV  by using 
> LSA type (based on AS scope Opaque Type , so the TLV is for External
> Prefixes)
> 
> But If we need to use the Prefix Range TLV for NSSA prefixes (Type-7) 
> , which are in area scope, there is no flag/route-type field in this 
> TLV to distinguish between Intra or NSSA prefixes( as IA flag will not 
> be set anyway).
> 
> Thanks & Regards,
> 
> Veerendranath
> 

___
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] draft-tgraf-ipfix-mpls-sr-label-type

[Ketan Talaulikar (ketant)]

Hi Thomas,

Thanks for your response. Let us also wait for inputs from others in the WGs.

One small bit.

[KT] By giving different types for OSPF and ISIS, is the intention to 
troubleshoot routing preference selection (done based on "admin distance" 
between protocol selection in RIB)?
Thomas> "admin distance" is one reason why one path is considered over another 
from two different protocols. In case of LDP vs IS-IS, in IOS-XR as an 
examples, it is "sr-prefer" configuration option.
KT2> The proposal to extend IE46 will cover the "sr-prefer" scenario and 
indicate whether the forwarding is happening with SR or LDP label. IMHO OSPF SR 
vs ISIS SR is perhaps not as useful?

Also, from an operational perspective (looking holistically), we have LSP 
ping/trace tools specified for MPLS (including SR segments/labels) to 
verify/validate consistency between forwarding and control plane to determine 
which protocol/label is being used and lot's more details.

Thanks,
Ketan

From: thomas.g...@swisscom.com 
Sent: 18 August 2020 18:28
To: Ketan Talaulikar (ketant) ; han...@gredler.at
Cc: lsr@ietf.org; spr...@ietf.org; ops...@ietf.org
Subject: RE: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type

Hi Ketan,

Thank you very much for the feedback.

[KT] Why not extend the existing IPFIX MPLS Label Type (value 46) to add SR 
Prefix SID, SR Adjacency SID, SR Binding SID ... (basically the segment types 
from RFC8402)? It's a simpler change to an existing element/field that makes it 
easier for routers, collectors and analysers?
Thomas> I am open to this approach to change IE46 to include segment types for 
RFC8402. I understand your concern to add additional fields. I would appreciate 
feedback from the wg if that is the path we like to go.

[KT] By giving different types for OSPF and ISIS, is the intention to 
troubleshoot routing preference selection (done based on "admin distance" 
between protocol selection in RIB)?
Thomas> "admin distance" is one reason why one path is considered over another 
from two different protocols. In case of LDP vs IS-IS, in IOS-XR as an 
examples, it is "sr-prefer" configuration option.

[KT] From the document, I believe we are still talking only about the top of 
the stack label ...
Thomas> Correct

[KT] My point is why do we need to introduce another ElementID and why not use 
the existing Type 46 as suggested above?
Thomas> See feedback above.


[KT] To be clear, I am not talking from the POV of a specific implementation. 
Let me summarize my feedback and perspective:

  *   Carefully consider the addition of more control plane elements and 
nuances into IPFIX since they require all that additional context/information 
to be made available at the "layer" (or component) from where IPFIX picks this 
info (traditionally from the "FIB"). This added information should have a 
strong enough justification of benefit - e.g. How does difference between Adj 
SID and LAN Adj SID matter?  How relevant it is to determine if the SR 
signaling protocol is OSPF or ISIS?
  *   Try to add/extend existing elements/fields with just the right amount and 
sufficient information that is necessary for flow analysis. We need to note 
that there may be many more/other sources for "off-box enrichment" of flow 
information collected and perhaps not everything needs to be determined and 
reported by routers.

Thomas> Absolutely. I fully agree on your feedback. We need to have the minimum 
possible in order to have a clear view about the MPL-SR forwarding. Since IPFIX 
using UDP for transport, without the possibility of fragmentation, we need to 
be careful as well not to add many more dimension's/fields.

Best Wishes
Thomas

From: Ketan Talaulikar (ketant) mailto:ket...@cisco.com>>
Sent: Monday, August 17, 2020 8:51 AM
To: Graf Thomas, INI-NET-DCF 
mailto:thomas.g...@swisscom.com>>; 
han...@gredler.at<mailto:han...@gredler.at>
Cc: lsr@ietf.org<mailto:lsr@ietf.org>; spr...@ietf.org<mailto:spr...@ietf.org>; 
ops...@ietf.org<mailto:ops...@ietf.org>
Subject: RE: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type

Hi Thomas,

Please check inline below.

From: thomas.g...@swisscom.com<mailto:thomas.g...@swisscom.com> 
mailto:thomas.g...@swisscom.com>>
Sent: 15 August 2020 11:31
To: Ketan Talaulikar (ketant) mailto:ket...@cisco.com>>; 
han...@gredler.at<mailto:han...@gredler.at>
Cc: lsr@ietf.org<mailto:lsr@ietf.org>; spr...@ietf.org<mailto:spr...@ietf.org>; 
ops...@ietf.org<mailto:ops...@ietf.org>
Subject: RE: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type

Hi Ketan,


  *   This helps identification of specific SR-MPLS segment types as well as 
differentiating them from LDP, RSVP-TE, etc.

To be precise, the existing MPLS Label Type identifier differentiates from LDP, 
RSVP-TE. Not the new SrSidType IPFIX IE being proposed.
[KT] Why not ext

Re: [Lsr] WG Last Call for draft-ietf-lsr-flex-algo

[Ketan Talaulikar (ketant)]

As a co-author, I am not aware of IPR beyond what has been already disclosed on 
this document.

Thanks,
Ketan

-Original Message-
From: Christian Hopps  
Sent: 18 August 2020 05:00
To: lsr@ietf.org
Cc: Christian Hopps ; lsr-...@ietf.org; Acee Lindem (acee) 
; draft-ietf-lsr-flex-algo@ietf.org
Subject: WG Last Call for draft-ietf-lsr-flex-algo

This begins a 2 week WG Last Call, ending after September 1st, 2020, for 
draft-ietf-lsr-flex-algo

  https://datatracker.ietf.org/doc/draft-ietf-lsr-flex-algo/

All authors, please indicate by sending an email to the list, whether you aware 
of any other IPR beyond what is already posted:

  [From 
https://datatracker.ietf.org/ipr/search/?submit=draft=draft-ietf-lsr-flex-algo]

  https://datatracker.ietf.org/ipr/3910/
  https://datatracker.ietf.org/ipr/3248/

Thanks,
Chris & Acee.

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

Re: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type

[Ketan Talaulikar (ketant)]

Hi Thomas,

Please check inline below.

From: thomas.g...@swisscom.com 
Sent: 15 August 2020 11:31
To: Ketan Talaulikar (ketant) ; han...@gredler.at
Cc: lsr@ietf.org; spr...@ietf.org; ops...@ietf.org
Subject: RE: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type

Hi Ketan,


  *   This helps identification of specific SR-MPLS segment types as well as 
differentiating them from LDP, RSVP-TE, etc.

To be precise, the existing MPLS Label Type identifier differentiates from LDP, 
RSVP-TE. Not the new SrSidType IPFIX IE being proposed.
[KT] Why not extend the existing IPFIX MPLS Label Type (value 46) to add SR 
Prefix SID, SR Adjacency SID, SR Binding SID ... (basically the segment types 
from RFC8402)? It's a simpler change to an existing element/field that makes it 
easier for routers, collectors and analysers?


  *   What value is provided for IPFIX analysis if the SR Prefix SID was being 
signalled via OSPF or ISIS?

It is important to distinguish between intend and result.
[KT] By giving different types for OSPF and ISIS, is the intention to 
troubleshoot routing preference selection (done based on "admin distance" 
between protocol selection in RIB)?

If you migrate from one label distribution protocol to another, a network 
operator want's to understand if the data plane is still forwarding packets 
with the label distribution protocol which needs to be removed or not. IE46 
enables that by looking at the result of the forwarded traffic and not at the 
intend. RFC 8661 section 3, https://tools.ietf.org/html/rfc8661#section-3, 
describes the context.
[KT] Sure, so adding the SR Segments to IE46, one can check whether the traffic 
forwarding is happening using LDP or SR labels at any link in the network.



  *   What value is provided for IPFIX analysis if it was a Adjacency SID or a 
LAN Adjacency SID?

Quote from RFC8402. "Segment Routing (SR) leverages the source routing 
paradigm". Means that not the routing protocol does all the forwarding 
decisions, the node can change the forwarding by pushing additional labels.
[KT] From the document, I believe we are still talking only about the top of 
the stack label ...

With IPFIX SrSidType we are able to cover this dimension in IPFIX. Enabling to 
analyze the result of this decision. The example with " Adjacency SID or a LAN 
Adjacency SID" is not very useful because the difference of the two is the 
topology among the adjacency. If you compare " Adjacency SID with Prefix SID", 
that makes much more sense. Since it describes that a particular adjacency is 
chosen to forward the packet instead of a prefix. If IE 89, ForwardingStatus is 
drop, we understand that result of that decision lead to the drop and this 
enables to narrow down forwarding issues in segment routing networks more 
efficiently and quickly.
[KT] My point is why do we need to introduce another ElementID and why not use 
the existing Type 46 as suggested above?


  *   am asking for WG to weigh the implementation complexities

For the WG and me, I would be important if you can describe more detailed what 
you mean with implementation complexities. I would like to have a better 
understanding where your fear is coming from. I would appreciate if you could 
differentiate between MPLS Label Type identifier, IE46, from which label 
protocol the label was coming from and SrSidType which SID type was used..
[KT] To be clear, I am not talking from the POV of a specific implementation. 
Let me summarize my feedback and perspective:

  *   Carefully consider the addition of more control plane elements and 
nuances into IPFIX since they require all that additional context/information 
to be made available at the "layer" (or component) from where IPFIX picks this 
info (traditionally from the "FIB"). This added information should have a 
strong enough justification of benefit - e.g. How does difference between Adj 
SID and LAN Adj SID matter?  How relevant it is to determine if the SR 
signaling protocol is OSPF or ISIS?
  *   Try to add/extend existing elements/fields with just the right amount and 
sufficient information that is necessary for flow analysis. We need to note 
that there may be many more/other sources for "off-box enrichment" of flow 
information collected and perhaps not everything needs to be determined and 
reported by routers.

Thanks,
Ketan

Best wishes
Thomas

From: Ketan Talaulikar (ketant) mailto:ket...@cisco.com>>
Sent: Saturday, August 15, 2020 7:09 AM
To: Graf Thomas, INI-NET-DCF 
mailto:thomas.g...@swisscom.com>>; 
han...@gredler.at<mailto:han...@gredler.at>
Cc: lsr@ietf.org<mailto:lsr@ietf.org>; spr...@ietf.org<mailto:spr...@ietf.org>; 
ops...@ietf.org<mailto:ops...@ietf.org>
Subject: RE: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type

Hi Thomas,

I should have been more clear in my email.

The proposal/suggestion is to add the following to the IPFIX MPLS Label type 
iden

Re: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type

[Ketan Talaulikar (ketant)]

Hi Thomas,

I should have been more clear in my email.

The proposal/suggestion is to add the following to the IPFIX MPLS Label type 
identifier registry:

  *   SR Prefix SID
  *   SR Adjacency SID
  *   SR Binding SID
  *   SR BGP Peering SID
  *   ... and so on

This helps identification of specific SR-MPLS segment types as well as 
differentiating them from LDP, RSVP-TE, etc.

And my questions were:

  1.  What value is provided for IPFIX analysis if the SR Prefix SID was being 
signalled via OSPF or ISIS?
  2.  What value is provided for IPFIX analysis if it was a Adjacency SID or a 
LAN Adjacency SID?

I am asking for WG to weigh the implementation complexities and overheads with 
the proposed details of SR-MPLS segments in IPFIX against the benefit (if any) 
that they provide for the flow analysis and monitoring.

Thanks,
Ketan

From: thomas.g...@swisscom.com 
Sent: 15 August 2020 09:40
To: Ketan Talaulikar (ketant) ; han...@gredler.at
Cc: lsr@ietf.org; spr...@ietf.org; ops...@ietf.org
Subject: RE: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type

Hi Ketan,

Thank you very much for the review and feedback.


  *   What or how much value be there on determining whether a SR Prefix SID 
was signalled/programmed on a node via OSPFv2/OSPFv3/ISIS - what matters and is 
more important is that it is a Prefix SID. Hardly any deployments would be 
running multiple protocols and learning the same prefix from different IGPs.

As Jeff already pointed out. Multiple IGP labelling protocols are used  in 
networks when migrations are ongoing. Usually in a life cycle. Migrating from 
LDP to OSPFv2/OSPFv3/ISIS SR TLV. This is/was also the case at Swisscom when we 
first discovered this shortcoming in vendor implementations. The key point 
here, with these additional IPFIX MPLS Label Type identifiers we enable the 
possibility to verify the label protocol migration without taking the label 
value into the consideration.


  *   IPFIX may be picking this information from a FIB in some implementation 
where the protocol does not matter and this information is not available 
therein.

I am not sure if you have seen the presentation in IETF 108 at OPSAWG and 
SPRING.
https://www.ietf.org/proceedings/108/slides/slides-108-opsawg-export-of-mpls-sr-label-type-information-in-ipfix-00.pdf

Slide 2 shows Cisco as example vendor which implemented IE 46, MPLS Label Type 
identifier. There is an open ddts where vendor feasibility has been clarified. 
Ping me off the list when you like to have more details.

I do understand your point that not all the vendors are capable to implement IE 
46. But that's not the point about the IPFIX IE registry. The IE registry 
enables that an IPFIX implementation can refer to the right code point. With 
RFC 5102 the decision has been made that MPLS Label Type identifier make sense 
and can be implemented. draft-tgraf-ipfix-mpls-sr-label-type just extends the 
IE 46 registry with the Segment Routing label protocol code points so when 
OSPFv2/OSPFv3/ISIS SR TLV is used, and IE 46 is supported, the IPFIX 
implementation can point to the right code point.


  *   On some nodes, the same Prefix SID may be learnt via both BGP and IGP - 
what would we use/show?

In this case the IE 46 shows the label protocol which was used to program the 
FIB.


  *   For that table proposal, it is very difficult and in some cases not 
possible to different between Prefix and Node and Anycast SID. Many of these 
types are control plane elements and we can be sure more get added.

I fully agree. As a network operator its still hard to understand the 
architecture and constraints within a router. When monitoring capabilities are 
discussed at IETF, this is the usual topic. What is possible, what make sense. 
By purpose, all available SID types are listed in the draft. This with the aim 
to start the discussion in the working groups what is possible what makes 
sense. I would be interested to get your and also Jeff's feedback.

In above mentioned slides I described how TI-LFA application would benefit of 
visibility in the FIB by showing where Adj-SID was used. This should be a 
simple example why it make sense not only to look at which label protocol was 
used to forward a particular packet, but also which SID type to further 
understand the intend why this label is being pushed.

I hope this makes all sense. Looking forward for reply.

Best wishes
Thomas

From: Ketan Talaulikar (ketant) mailto:ket...@cisco.com>>
Sent: Friday, August 14, 2020 7:35 PM
To: Graf Thomas, INI-NET-DCF 
mailto:thomas.g...@swisscom.com>>; 
han...@gredler.at<mailto:han...@gredler.at>
Cc: lsr@ietf.org<mailto:lsr@ietf.org>; SPRING WG 
mailto:spr...@ietf.org>>
Subject: RE: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type

< also copying Spring WG for their review/inputs >

Hi Thomas/All,

I have reviewed the draft and would like to share a different perspective.

What or how much value be there on determining whether a SR 

Re: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type

[Ketan Talaulikar (ketant)]

< also copying Spring WG for their review/inputs >

Hi Thomas/All,

I have reviewed the draft and would like to share a different perspective.

What or how much value be there on determining whether a SR Prefix SID was 
signalled/programmed on a node via OSPFv2/OSPFv3/ISIS - what matters and is 
more important is that it is a Prefix SID. Hardly any deployments would be 
running multiple protocols and learning the same prefix from different IGPs. 
IPFIX may be picking this information from a FIB in some implementation where 
the protocol does not matter and this information is not available therein.

On some nodes, the same Prefix SID may be learnt via both BGP and IGP - what 
would we use/show?

I would recommend using SR Prefix SID, SR Adjacency SID, SR Binding SID, SR BGP 
Peering SID and so on ... for the MPLS Label Type.

This also takes away the need for the second table that is being proposed to a 
large extent. For that table proposal, it is very difficult and in some cases 
not possible to different between Prefix and Node and Anycast SID. Many of 
these types are control plane elements and we can be sure more get added. Is 
there really much value in differentiation between say an Adjacency SID and LAN 
Adjacency SID?

Could we evaluate the implementation overhead and complexity of this level of 
categorization/information in IPFIX against their value in flow analysis to 
perhaps consider a middle ground?

Thanks,
Ketan

From: Lsr  On Behalf Of thomas.g...@swisscom.com
Sent: 31 July 2020 20:52
To: han...@gredler.at
Cc: lsr@ietf.org
Subject: Re: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type

Hi Hannes,

Thanks a lot for the feedback. Yes, makes completely sense. Will take it for 
the next update..

Best Wishes
Thomas


From: Hannes Gredler mailto:han...@gredler.at>>
Sent: Wednesday, July 29, 2020 9:31 AM
To: Graf Thomas, INI-NET-DCF 
mailto:thomas.g...@swisscom.com>>
Cc: lsr@ietf.org
Subject: Re: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type

Thomas,

I have one comment/suggestion to Paragraph 4 (IANA Considerations).

Please add also a code point for BGP Prefix-SID - it's quite popular in DC 
deployments.
https://tools.ietf.org/html/rfc8669

thanks,

/hannes

On 28.07.2020, at 10:11, 
thomas.g...@swisscom.com wrote:

Dear lsr,

I presented the following draft

Export of MPLS Segment Routing Label Type Information in IP Flow Information 
Export (IPFIX)
https://tools.ietf.org/html/draft-tgraf-ipfix-mpls-sr-label-type-04

at the spring working group at IETF 108 yesterday
https://www.ietf.org/proceedings/108/slides/slides-108-spring-ip-flow-information-export-ipfix-00.pdf

and today at OPSAWG where I call for adoption.

This draft adds additional segment routing code points for in the IANA IPFIX 
registry for IS-IS, OPSFv2 and OPSF v3 and segment routing SID types to gain 
further insights into the MPLS-SR forwarding-plane.

I have been asked to not only gather feedback from spring and opsawg but also 
from lsr and mpls working groups since these code points are related to link 
state routing protocols and mpls data plane.

I am looking forward to your feedback and input.

Best Wishes
Thomas Graf
___
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] [IANA #1173602] Re: IANA early allocation request for draft-ietf-lsr-ospf-bfd-strict-mode

[Ketan Talaulikar (ketant)]

Thanks Amanda.

-Original Message-
From: Lsr  On Behalf Of Amanda Baber via RT
Sent: 09 July 2020 01:37
To: Acee Lindem (acee) 
Cc: alvaro.ret...@futurewei.com; Ketan Talaulikar (ketant) ; 
gunter.van_de_ve...@nokia.com; mraj...@juniper.net; 
acee=40cisco@dmarc.ietf.org; lsr@ietf.org; aretana.i...@gmail.com; Peter 
Psenak (ppsenak) 
Subject: [Lsr] [IANA #1173602] Re: IANA early allocation request for 
draft-ietf-lsr-ospf-bfd-strict-mode

Hi Peter, Ketan, Acee, 

We've added a permanent entry for B-bit in the LLS Type 1 Extended Options and 
Flags registry and moved the Flooding Request bit registration to 0x0020:

0x0010  B-bit   [draft-ietf-lsr-ospf-bfd-strict-mode-01]
0x0020  Flooding Request bit[draft-ietf-lsr-dynamic-flooding]

Please see
https://www.iana.org/assignments/ospf-lls-tlvs

Best regards,

Amanda Baber
Lead IANA Services Specialist

On Wed Jul 08 08:53:07 2020, ppse...@cisco.com wrote:
> Amanda,
> 
> On 07/07/2020 22:54, Amanda Baber via RT wrote:
> > Peter, should we go ahead?
> 
> yes, please.
> 
> thanks,
> Peter
> 
> > 
> > thanks,
> > Amanda
> > 
> > On Tue Jul 07 20:14:48 2020, a...@cisco.com wrote:
> >> Gunter is on vacation...
> >> Thanks,
> >> Acee
> >>
> >> On 7/6/20, 1:14 PM, "Amanda Baber via RT" 
> >> 
> >> wrote:
> >>
> >> Hi Ketan, Peter,
> >>
> >> I believe we're waiting for Gunter to approve as the remaining 
> >> expert, but we can move ahead if Peter confirms that we don't need to wait.
> >>
> >> Best regards,
> >> Amanda
> >>
> >> On Mon Jul 06 03:46:02 2020, ket...@cisco.com wrote:
> >>> Hi Amanda/All,
> >>>
> >>> I thought that there was an agreement to assign bit 0x0010 for 
> >>> draft-ietf-lsr-ospf-bfd-strict-mode and 0x0020 for draft-ietf-
> >>> lsr-
> >>> dynamic-flooding?
> >>>
> >>> Thanks,
> >>> Ketan
> >>>
> >>> -Original Message-
> >>>   From: Amanda Baber via RT 
> >>> Sent: 04 July 2020 07:53
> >>> To: Acee Lindem (acee) 
> >>> Cc: Peter Psenak (ppsenak) ; 
> >>> mraj...@juniper.net; lsr@ietf.org; Ketan Talaulikar (ketant) 
> >>> ; gunter.van_de_ve...@nokia.com; 
> >>> aretana.i...@gmail.com; alvaro.ret...@futurewei.com; 
> >>> acee=40cisco@dmarc.ietf.org
> >>> Subject: [IANA #1173602] Re: IANA early allocation request for 
> >>> draft- ietf-lsr-ospf-bfd-strict-mode
> >>>
> >>> Hi Peter, all,
> >>>
> >>>>> For both Peter and Gunter: the Flooding Request bit registration 
> >>>>> is described in the registry as a temporary allocation, but this 
> >>>>> may have been an mistake The RFC 7120 temporary early allocation 
> >>>>> procedure is meant for registries that require RFC publication 
> >>>>> for permanent registration. In theory, if the experts agree, 
> >>>>> permanent registrations can be made in Expert Review registries 
> >>>>> at any time.
> >>>>> Would there be an issue with removing the "TEMPORARY" 
> >>>>> designation from that registration?
> >>>>
> >>>> please go ahead and remove the TEMPORARY.
> >>>
> >>> The "TEMPORARY" designation has been removed from the 
> >>> draft-ietf-lsr- dynamic-flooding registration in LLS Type 1 
> >>> Extended Options and Flags, currently still assigned 0x0010:
> >>>
> >>> https://www.iana.org/assignments/ospf-lls-tlvs
> >>>
> >>> thanks,
> >>> Amanda
> >>
> >>
> > 
> > 
> > 
> 

___
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] [IANA #1173602] Re: IANA early allocation request for draft-ietf-lsr-ospf-bfd-strict-mode

[Ketan Talaulikar (ketant)]

Hi Amanda/All,

I thought that there was an agreement to assign bit 0x0010 for 
draft-ietf-lsr-ospf-bfd-strict-mode and 0x0020 for 
draft-ietf-lsr-dynamic-flooding?

Thanks,
Ketan

-Original Message-
From: Amanda Baber via RT  
Sent: 04 July 2020 07:53
To: Acee Lindem (acee) 
Cc: Peter Psenak (ppsenak) ; mraj...@juniper.net; 
lsr@ietf.org; Ketan Talaulikar (ketant) ; 
gunter.van_de_ve...@nokia.com; aretana.i...@gmail.com; 
alvaro.ret...@futurewei.com; acee=40cisco@dmarc.ietf.org
Subject: [IANA #1173602] Re: IANA early allocation request for 
draft-ietf-lsr-ospf-bfd-strict-mode

Hi Peter, all,

> > For both Peter and Gunter: the Flooding Request bit registration is 
> > described in the registry as a temporary allocation, but this may 
> > have been an mistake The RFC 7120 temporary early allocation 
> > procedure is meant for registries that require RFC publication for 
> > permanent registration. In theory, if the experts agree, permanent 
> > registrations can be made in Expert Review registries at any time.
> > Would there be an issue with removing the "TEMPORARY" designation 
> > from that registration?
> 
> please go ahead and remove the TEMPORARY.

The "TEMPORARY" designation has been removed from the 
draft-ietf-lsr-dynamic-flooding registration in LLS Type 1 Extended Options and 
Flags, currently still assigned 0x0010:

https://www.iana.org/assignments/ospf-lls-tlvs

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

Re: [Lsr] [IANA #1173602] Re: IANA early allocation request for draft-ietf-lsr-ospf-bfd-strict-mode

[Ketan Talaulikar (ketant)]

+1

-Original Message-
From: Peter Psenak  
Sent: 02 July 2020 13:11
To: Acee Lindem (acee) ; iana-prot-pa...@iana.org
Cc: lsr@ietf.org; Ketan Talaulikar (ketant) ; 
gunter.van_de_ve...@nokia.com; alvaro.ret...@futurewei.com
Subject: Re: [IANA #1173602] Re: IANA early allocation request for 
draft-ietf-lsr-ospf-bfd-strict-mode

Hi Ketan, Acee,

On 01/07/2020 23:24, Acee Lindem (acee) wrote:
> Hi Amanda,
> 
> On 7/1/20, 5:10 PM, "Amanda Baber via RT"  wrote:
> 
>  Hi Acee, Alvaro, all,
> 
>  Alvaro: can you approve the request for early registration of the B-bit 
> in the LLS Type 1 Extended Options and Flags registry at 
> https://www.iana.org/assignments/ospf-lls-tlvs?
> 
>  Acee, Ketan: the document says that it's registering 0x0010, but 
> that value was allocated to draft-ietf-lsr-dynamic-flooding last year. If 
> Alvaro approves, should we register 0x0020 instead?

I doubt there is any OSPF implementation of draft-ietf-lsr-dynamic-flooding, so 
it may be safer to use the
0x0010 for draft-ietf-lsr-ospf-bfd-strict-mode and 0x0020 for 
draft-ietf-lsr-dynamic-flooding.

thanks,
Peter

> 
> Yes. While a few implementations have the BFD strict-mode configuration, I 
> don't believe any have shipped the LLS signaling yet.
> 
>  Acee, Ketan, Gunter, Peter: because it's using a different registration 
> procedure, I'm creating a separate ticket for the Link Local Signalling TLV 
> Identifiers (LLS Types) registration. I'll send an expert review request from 
> that ticket.
> 
> Fine - Thanks,
> Acee
> 
>  Best regards,
> 
>  Amanda Baber
>  Lead IANA Services Specialist
> 
>  On Wed Jul 01 19:38:00 2020, a...@cisco.com wrote:
>  > Hi Ketan,  IANA, Alvaro,
>  > I don't see any problem with early allocation of this LLS bit and TLV
>  > - pretty straight forward. It would make sense to put the respective
>  > registries in the IANA section (included below for info).
>  >
>  > Open Shortest Path First (OSPF) Link Local Signalling (LLS) -
>  > Type/Length/Value Identifiers (TLV)
>  >   Link Local Signalling TLV Identifiers (LLS Types) RFC 5613
>  >   IETF Review
>  >   LLS Type 1 Extended Options and Flags RFC 5613
>  >  Expert Review (Expert: Gunter Van De Velde, Peter Psenak)
>  >
>  > For the flag, the designated experts are Gunter and Peter (copied).
>  >
>  > Please initiate the early allocation process pending expert and AD
>  > approval.
>  > Thanks,
>  > Acee
>  >
>  > On 6/30/20, 4:58 AM, "Ketan Talaulikar (ketant)" 
>  > wrote: ts
>  >
>  > Hello Acee/Chris,
>  >
>  > The authors would like to request IANA early allocations for this
>  > draft.
>  >
>  > Thanks,
>  > Ketan (on behalf of co-authors)
>  >
>  > -Original Message-
>  >  From: Ketan Talaulikar (ketant)
>  > Sent: 30 June 2020 14:25
>  > To: lsr@ietf.org
>  > Subject: RE: [Lsr] I-D Action: draft-ietf-lsr-ospf-bfd-strict-mode-
>  > 01.txt
>  >
>  > Hi All,
>  >
>  > This is mostly a refresh with editorial updates. We look forward to
>  > review and feedback.
>  >
>  > Thanks,
>  > Ketan (on behalf of co-authors)
>  >
>  > -Original Message-
>  > From: Lsr  On Behalf Of internet-dra...@ietf.org
>  > Sent: 30 June 2020 14:20
>  > To: i-d-annou...@ietf.org
>  > Cc: lsr@ietf.org
>  > Subject: [Lsr] I-D Action: draft-ietf-lsr-ospf-bfd-strict-mode-01.txt
>  >
>  >
>  > 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   : OSPF Strict-Mode for BFD
>  > Authors : Ketan Talaulikar
>  >   Peter Psenak
>  >   Albert Fu
>  >   Rajesh M
>  > Filename: draft-ietf-lsr-ospf-bfd-strict-mode-01.txt
>  > Pages   : 10
>  > Date: 2020-06-30
>  >
>  > Abstract:
>  >This document specifies the extensions to OSPF that enable an OSPF
>  >router to signal the requirement for a Bidirectional Forwarding
>  >Detection (BFD) session prior to adjacency formation.  Link-Local
>  >Signaling (LLS) is used to advertise this requirement o

[Lsr] WG adoption request for draft-ketant-lsr-ospf-l2bundles

[Ketan Talaulikar (ketant)]

Hello Acee/Chris,

Would like to request for WG adoption for 
https://datatracker.ietf.org/doc/draft-ketant-lsr-ospf-l2bundles/ 

The draft was presented at IETF 105 and has not changed much since then. There 
have been requests from operators using OSPF to provide the equivalent 
functionality as RFC8668 provided for IS-IS.

Thanks,
Ketan

-Original Message-
From: internet-dra...@ietf.org  
Sent: 30 June 2020 20:01
To: Peter Psenak (ppsenak) ; Ketan Talaulikar (ketant) 

Subject: New Version Notification for draft-ketant-lsr-ospf-l2bundles-02.txt


A new version of I-D, draft-ketant-lsr-ospf-l2bundles-02.txt
has been successfully submitted by Ketan Talaulikar and posted to the IETF 
repository.

Name:   draft-ketant-lsr-ospf-l2bundles
Revision:   02
Title:  Advertising L2 Bundle Member Link Attributes in OSPF
Document date:  2020-06-30
Group:  Individual Submission
Pages:  10
URL:
https://www.ietf.org/internet-drafts/draft-ketant-lsr-ospf-l2bundles-02.txt
Status: 
https://datatracker.ietf.org/doc/draft-ketant-lsr-ospf-l2bundles/
Htmlized:   https://tools.ietf.org/html/draft-ketant-lsr-ospf-l2bundles-02
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-ketant-lsr-ospf-l2bundles
Diff:   
https://www.ietf.org/rfcdiff?url2=draft-ketant-lsr-ospf-l2bundles-02

Abstract:
   There are deployments where the Layer 3 interface on which OSPF
   operates is a Layer 2 interface bundle.  Existing OSPF advertisements
   only support advertising link attributes of the Layer 3 interface.
   If entities external to OSPF wish to control traffic flows on the
   individual physical links which comprise the Layer 2 interface bundle
   link attribute information about the bundle members is required.

   This document introduces the ability for OSPF to advertise the link
   attributes of layer 2 (L2) Bundle members.


  


Please note that it may take a couple of minutes from the time of submission 
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


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

[Lsr] IANA early allocation request for draft-ietf-lsr-ospf-bfd-strict-mode

[Ketan Talaulikar (ketant)]

Hello Acee/Chris,

The authors would like to request IANA early allocations for this draft.

Thanks,
Ketan (on behalf of co-authors)

-Original Message-
From: Ketan Talaulikar (ketant) 
Sent: 30 June 2020 14:25
To: lsr@ietf.org
Subject: RE: [Lsr] I-D Action: draft-ietf-lsr-ospf-bfd-strict-mode-01.txt

Hi All,

This is mostly a refresh with editorial updates. We look forward to review and 
feedback.

Thanks,
Ketan (on behalf of co-authors)

-Original Message-
From: Lsr  On Behalf Of internet-dra...@ietf.org
Sent: 30 June 2020 14:20
To: i-d-annou...@ietf.org
Cc: lsr@ietf.org
Subject: [Lsr] I-D Action: draft-ietf-lsr-ospf-bfd-strict-mode-01.txt


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   : OSPF Strict-Mode for BFD
Authors : Ketan Talaulikar
  Peter Psenak
  Albert Fu
  Rajesh M
Filename: draft-ietf-lsr-ospf-bfd-strict-mode-01.txt
Pages   : 10
Date: 2020-06-30

Abstract:
   This document specifies the extensions to OSPF that enable an OSPF
   router to signal the requirement for a Bidirectional Forwarding
   Detection (BFD) session prior to adjacency formation.  Link-Local
   Signaling (LLS) is used to advertise this requirement of "strict-
   mode" of BFD session establishment for OSPF adjacency.  If both OSPF
   neighbors advertise the "strict-mode" of BFD, adjacency formation
   will be blocked until a BFD session has been successfully
   established.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-bfd-strict-mode/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-lsr-ospf-bfd-strict-mode-01
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospf-bfd-strict-mode-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-lsr-ospf-bfd-strict-mode-01


Please note that it may take a couple of minutes from the time of submission 
until the htmlized version and diff are available at tools.ietf.org.

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 mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] I-D Action: draft-ietf-lsr-ospf-bfd-strict-mode-01.txt

[Ketan Talaulikar (ketant)]

Hi All,

This is mostly a refresh with editorial updates. We look forward to review and 
feedback.

Thanks,
Ketan (on behalf of co-authors)

-Original Message-
From: Lsr  On Behalf Of internet-dra...@ietf.org
Sent: 30 June 2020 14:20
To: i-d-annou...@ietf.org
Cc: lsr@ietf.org
Subject: [Lsr] I-D Action: draft-ietf-lsr-ospf-bfd-strict-mode-01.txt


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   : OSPF Strict-Mode for BFD
Authors : Ketan Talaulikar
  Peter Psenak
  Albert Fu
  Rajesh M
Filename: draft-ietf-lsr-ospf-bfd-strict-mode-01.txt
Pages   : 10
Date: 2020-06-30

Abstract:
   This document specifies the extensions to OSPF that enable an OSPF
   router to signal the requirement for a Bidirectional Forwarding
   Detection (BFD) session prior to adjacency formation.  Link-Local
   Signaling (LLS) is used to advertise this requirement of "strict-
   mode" of BFD session establishment for OSPF adjacency.  If both OSPF
   neighbors advertise the "strict-mode" of BFD, adjacency formation
   will be blocked until a BFD session has been successfully
   established.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-bfd-strict-mode/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-lsr-ospf-bfd-strict-mode-01
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospf-bfd-strict-mode-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-lsr-ospf-bfd-strict-mode-01


Please note that it may take a couple of minutes from the time of submission 
until the htmlized version and diff are available at tools.ietf.org.

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 mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] I-D Action: draft-ietf-lsr-ospf-prefix-originator-06.txt

[Ketan Talaulikar (ketant)]

Hi All,

We've recently submitted an update to this draft with the following changes:

1)  Introduced a new Prefix Originator Sub-TLV for carrying the reachable 
address of the node originating the prefix advertisement. This is equivalent to 
the similar ISIS extension - https://tools.ietf.org/html/rfc7794#section-2.2.
2) Removed the text related to use-case/justification for ELC since that no 
longer applies now with the updated IGP ELC drafts where this capability is now 
advertised as a prefix attribute. 
3) Removed references to ERLD and MSD since the originator node is the 
destination and not the transit or ingress for the flows towards the specific 
prefix.
4) Moved some remaining topology reconstruction use-case related text into the 
Appendix since it is non-normative.
5) Clarified and updated the procedures with normative text describing the 
origination of the sub-TLVs in more detail.
6) Other minor editorial changes.

Look forward to the WG review and feedback on this.

Thanks,
Ketan (on behalf of co-authors)

-Original Message-
From: Lsr  On Behalf Of internet-dra...@ietf.org
Sent: 30 June 2020 13:59
To: i-d-annou...@ietf.org
Cc: lsr@ietf.org
Subject: [Lsr] I-D Action: draft-ietf-lsr-ospf-prefix-originator-06.txt


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   : OSPF Prefix Originator Extensions
Authors : Aijun Wang
  Acee Lindem
  Jie Dong
  Peter Psenak
  Ketan Talaulikar
Filename: draft-ietf-lsr-ospf-prefix-originator-06.txt
Pages   : 11
Date: 2020-06-30

Abstract:
   This document defines OSPF extensions to include information
   associated with the node originating a prefix along with the prefix
   advertisement.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-prefix-originator/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-lsr-ospf-prefix-originator-06
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospf-prefix-originator-06

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-lsr-ospf-prefix-originator-06


Please note that it may take a couple of minutes from the time of submission 
until the htmlized version and diff are available at tools.ietf.org.

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 mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] draft-ietf-lsr-flex-algo

[Ketan Talaulikar (ketant)]

Hi Wang,

You are correct. Though I wouldn't call it a goal but rather a 
benefit/advantage - same applies to SR-MPLS where the label stack can be 
reduced.

Thanks,
Ketan

From: Lsr  On Behalf Of Wang, Weibin (NSB - CN/Shanghai)
Sent: 08 May 2020 19:07
To: lsr@ietf.org
Subject: [Lsr] draft-ietf-lsr-flex-algo

Hi authors:

After reading through this draft lsr-flex-algo, I want to know whether there is 
a potential goal of this draft to reduce the SRH size with enabling flex-algo 
with admin group in SRv6 deployment, because without flex-algo we have to have 
a big SRH size when the SRH include more SRv6 SIDs, if we enable flex-algo 
under special topology and link constraint condition, in theory we can even 
construct  a end to end SR path/tunnel without SRH, but it still meet TE 
requirement. So my question is whether the flex-algo can be used as tool to 
reduce SRH size?



Cheers !

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

Re: [Lsr] clarification of locator block and locator node in draft-ietf-spring-srv6-network-programming and draft-ietf-lsr-isis-srv6-extensions

[Ketan Talaulikar (ketant)]

Hi Chris,

I am repeating the use-case described previously:
The IGP drafts covers the advertisement of the B and N parts of the locally 
configured locator on the node via IGPs. On the receiver side, the IGP may not 
really do much with this information, however it enables propagation of this 
information from all nodes in the network to be advertised out via BGP-LS (or 
other mechanisms) as part of the topology feed. Once this is part of the 
topology feed, it enables use-cases on controllers to perform network wide 
validation of the SRv6 SID block provisioning and can also help in automation 
of the security aspects described in 
https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-26#section-5
We do carry information in the IGPs for propagation as part of the topology 
information for enabling use-cases outside the router (e.g. via BGP-LS). We do 
not need to preclude a use-case for it in IGPs themselves in the future.

Thanks,
Ketan

From: Chris Bowers 
Sent: 12 March 2020 20:29
To: Peter Psenak (ppsenak) ; Ketan Talaulikar (ketant) 

Cc: lsr@ietf.org; SPRING WG List ; Bruno Decraene 

Subject: Re: [Lsr] clarification of locator block and locator node in 
draft-ietf-spring-srv6-network-programming and 
draft-ietf-lsr-isis-srv6-extensions

Peter,

I think that the SRv6 SID Structure Sub-Sub-TLV should be removed from 
draft-ietf-lsr-isis-srv6-extensions.  I think that we should leave the ability 
to include sub-sub-TLVs in the SRv6 End SID Sub-TLV, End.X SID Sub-TLV, and LAN 
End.X SID Sub-TLV in the encodings for those sub-TLVs.

I don't think that the current text describing the SRv6 SID Structure 
Sub-Sub-TLV would result in interoperable implementations.  Based on the 
discussion with Ketan below, it appears that use cases for ISIS speakers 
receiving advertised values of LB Length, LN Length, Fun. Length, and Arg. 
Length are not currently well-defined.So I think it makes sense to defer 
the definition of the SRv6 SID Structure Sub-Sub-TLV to a future document.

Thanks,
Chris

On Thu, Mar 12, 2020 at 6:02 AM Ketan Talaulikar (ketant) 
mailto:ket...@cisco.com>> wrote:
Hi Chris,

Dropping the draft-ietf-spring-srv6-network-programming authors since we are 
now back to discussing the ISIS extensions.

Please check inline below.

From: Chris Bowers 
mailto:chrisbowers.i...@gmail.com>>
Sent: 05 March 2020 21:53
To: Ketan Talaulikar (ketant) mailto:ket...@cisco.com>>
Cc: Ketan Talaulikar (ketant) mailto:ket...@cisco.com>>; 
lsr@ietf.org<mailto:lsr@ietf.org>; SPRING WG List 
mailto:spr...@ietf.org>>; 
draft-ietf-spring-srv6-network-programming 
mailto:draft-ietf-spring-srv6-network-programm...@ietf.org>>;
 Peter Psenak (ppsenak) mailto:ppse...@cisco.com>>; Bruno 
Decraene mailto:bruno.decra...@orange.com>>
Subject: Re: [Lsr] clarification of locator block and locator node in 
draft-ietf-spring-srv6-network-programming and 
draft-ietf-lsr-isis-srv6-extensions

Ketan,

See inline [CB].

On Wed, Mar 4, 2020 at 12:36 AM Ketan Talaulikar (ketant) 
mailto:ket...@cisco.com>> wrote:
Hi Chris,

You are right in that there is no assumption that all SRv6 locators in a domain 
are allocated from the same block. Therefore knowing the blocks used in the 
domain is useful.

[CB] Since you refer to "blocks" (plural) in this sentence, are you saying that 
in the scenario where all SRv6 locators in a domain are not allocated from the 
same block, you would expect different routers in the same domain to advertise 
different values of B and N?
[KT] While personally I believe it would not be the usual case, it is left to 
the operator.

For example, assume we have a network where all SRv6 locators in a domain are 
not allocated from the same block.  Router A advertises an SRv6 Locator TLV 
with locator = 2000::/64, and an SRv6 End SID sub-TLV with some endpoint 
behavior.  Router B advertises an SRv6 Locator TLV with locator = 3000::/64, 
and an SRv6 End SID sub-TLV with some endpoint behavior. What should routers A 
and B advertise as the values of B and N in their SRv6 SID Structure 
Sub-Sub-TLVs ?
[KT] It is difficult for me to figure out what the block and node parts are 
with such an addressing.


The IGP drafts covers the advertisement of the B and N parts of the locally 
configured locator on the node via IGPs. On the receiver side, the IGP may not 
really do much with this information, however it enables propagation of this 
information from all nodes in the network to be advertised out via BGP-LS (or 
other mechanisms) as part of the topology feed. Once this is part of the 
topology feed, it enables use-cases on controllers to perform network wide 
validation of the SRv6 SID block provisioning and can also help in automation 
of the security aspects described in 
https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-26#section-5

[CB] If an ISIS speaker is not expected to do anything with B and N, then I 
think the

Re: [Lsr] [spring] clarification of locator block and locator node in draft-ietf-spring-srv6-network-programming and draft-ietf-lsr-isis-srv6-extensions

[Ketan Talaulikar (ketant)]

Hi Chris,

I've been following that thread 

IMHO it would depend on the nature of extension and seems not something that I 
would speculate about.

Thanks,
Ketan

-Original Message-
From: Lsr  On Behalf Of Christian Hopps
Sent: 12 March 2020 17:04
To: spr...@ietf.org
Cc: Chris Bowers ; lsr@ietf.org; Peter Psenak 
(ppsenak) ; Bruno Decraene 
Subject: Re: [Lsr] [spring] clarification of locator block and locator node in 
draft-ietf-spring-srv6-network-programming and 
draft-ietf-lsr-isis-srv6-extensions


Ketan Talaulikar (ketant)  writes:

> [KT] The behaviors currently listed in the draft do not have an argument nor 
> is the use of B and N required for them. We cannot preclude a future use-case 
> or extension where such behaviors introduced are also applicable to ISIS. So 
> IMHO ruling such aspects out might not be the right thing to do from a 
> protocol extensibility perspective.

No opinion here on this sub-sub-TLV; however, it has been stated elsewhere that 
this document will be re-spun for each new behavior that is to be carried in 
IS-IS (not my personal preference, fwiw...).

Thanks,
Chris.
[as WG member]
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] clarification of locator block and locator node in draft-ietf-spring-srv6-network-programming and draft-ietf-lsr-isis-srv6-extensions

[Ketan Talaulikar (ketant)]

Hi Chris,

Dropping the draft-ietf-spring-srv6-network-programming authors since we are 
now back to discussing the ISIS extensions.

Please check inline below.

From: Chris Bowers 
Sent: 05 March 2020 21:53
To: Ketan Talaulikar (ketant) 
Cc: Ketan Talaulikar (ketant) ; lsr@ietf.org; SPRING WG List 
; draft-ietf-spring-srv6-network-programming 
; Peter Psenak (ppsenak) 
; Bruno Decraene 
Subject: Re: [Lsr] clarification of locator block and locator node in 
draft-ietf-spring-srv6-network-programming and 
draft-ietf-lsr-isis-srv6-extensions

Ketan,

See inline [CB].

On Wed, Mar 4, 2020 at 12:36 AM Ketan Talaulikar (ketant) 
mailto:ket...@cisco.com>> wrote:
Hi Chris,

You are right in that there is no assumption that all SRv6 locators in a domain 
are allocated from the same block. Therefore knowing the blocks used in the 
domain is useful.

[CB] Since you refer to "blocks" (plural) in this sentence, are you saying that 
in the scenario where all SRv6 locators in a domain are not allocated from the 
same block, you would expect different routers in the same domain to advertise 
different values of B and N?
[KT] While personally I believe it would not be the usual case, it is left to 
the operator.

For example, assume we have a network where all SRv6 locators in a domain are 
not allocated from the same block.  Router A advertises an SRv6 Locator TLV 
with locator = 2000::/64, and an SRv6 End SID sub-TLV with some endpoint 
behavior.  Router B advertises an SRv6 Locator TLV with locator = 3000::/64, 
and an SRv6 End SID sub-TLV with some endpoint behavior. What should routers A 
and B advertise as the values of B and N in their SRv6 SID Structure 
Sub-Sub-TLVs ?
[KT] It is difficult for me to figure out what the block and node parts are 
with such an addressing.


The IGP drafts covers the advertisement of the B and N parts of the locally 
configured locator on the node via IGPs. On the receiver side, the IGP may not 
really do much with this information, however it enables propagation of this 
information from all nodes in the network to be advertised out via BGP-LS (or 
other mechanisms) as part of the topology feed. Once this is part of the 
topology feed, it enables use-cases on controllers to perform network wide 
validation of the SRv6 SID block provisioning and can also help in automation 
of the security aspects described in 
https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-26#section-5

[CB] If an ISIS speaker is not expected to do anything with B and N, then I 
think the text in draft-ietf-lsr-isis-srv6-extensions needs to clarify this.  I 
have a similar observation about Fun. Length and Arg. Length in the SRv6 SID 
Structure Sub-Sub-TLV .  As far as I can tell, none of the endpoint behaviors 
that are currently specified to be carried in ISIS End, End.X, and LAN End.X 
SIDs sub-TLVs uses an Argument, so there is never a case where an SRv6 SID 
Structure Sub-Sub-TLV should have a non-zero value for Arg. Length. What should 
an ISIS speaker do if it receives a non-zero value of the Arg. Length for an 
endpoint behavior that doesn't use an argument?  Are there any use cases 
envisioned where an ISIS speaker needs to know the Arg. Length ?
[KT] The behaviors currently listed in the draft do not have an argument nor is 
the use of B and N required for them. We cannot preclude a future use-case or 
extension where such behaviors introduced are also applicable to ISIS. So IMHO 
ruling such aspects out might not be the right thing to do from a protocol 
extensibility perspective.

Thanks,
Ketan

Thanks,
Ketan

From: Chris Bowers 
mailto:chrisbowers.i...@gmail.com>>
Sent: 02 March 2020 23:39
To: Ketan Talaulikar (ketant) mailto:ket...@cisco.com>>
Cc: Ketan Talaulikar (ketant) 
mailto:40cisco.@dmarc.ietf.org>>; 
lsr@ietf.org<mailto:lsr@ietf.org>; SPRING WG List 
mailto:spr...@ietf.org>>; 
draft-ietf-spring-srv6-network-programming 
mailto:draft-ietf-spring-srv6-network-programm...@ietf.org>>;
 Peter Psenak (ppsenak) mailto:ppse...@cisco.com>>; Bruno 
Decraene mailto:bruno.decra...@orange.com>>
Subject: Re: [Lsr] clarification of locator block and locator node in 
draft-ietf-spring-srv6-network-programming and 
draft-ietf-lsr-isis-srv6-extensions

Ketan,

Based on current documents, allocating all SRv6 locators used in a domain from 
a single block is optional.

However, assuming for the moment that a network operator has chosen to allocate 
all SRv6 locators used in a domain from a single block, so that there is a 
well-defined value of B and N across a domain, what is the use of having a 
router advertise its own understanding of these two values?  And what is a 
receiver supposed to do with this information?

Thanks,
Chris

On Fri, Feb 28, 2020 at 8:23 AM 
mailto:bruno.decra...@orange.com>> wrote:
Hi Ketan,

Thanks fort the follow up.
Clarification inline [Bruno]

From: Ketan Talaulikar (ketant) 
[mailto:ket...@

Re: [Lsr] clarification of locator block and locator node in draft-ietf-spring-srv6-network-programming and draft-ietf-lsr-isis-srv6-extensions

[Ketan Talaulikar (ketant)]

Hi Chris,

You are right in that there is no assumption that all SRv6 locators in a domain 
are allocated from the same block. Therefore knowing the blocks used in the 
domain is useful.

The IGP drafts covers the advertisement of the B and N parts of the locally 
configured locator on the node via IGPs. On the receiver side, the IGP may not 
really do much with this information, however it enables propagation of this 
information from all nodes in the network to be advertised out via BGP-LS (or 
other mechanisms) as part of the topology feed. Once this is part of the 
topology feed, it enables use-cases on controllers to perform network wide 
validation of the SRv6 SID block provisioning and can also help in automation 
of the security aspects described in 
https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-26#section-5

Thanks,
Ketan

From: Chris Bowers 
Sent: 02 March 2020 23:39
To: Ketan Talaulikar (ketant) 
Cc: Ketan Talaulikar (ketant) ; 
lsr@ietf.org; SPRING WG List ; 
draft-ietf-spring-srv6-network-programming 
; Peter Psenak (ppsenak) 
; Bruno Decraene 
Subject: Re: [Lsr] clarification of locator block and locator node in 
draft-ietf-spring-srv6-network-programming and 
draft-ietf-lsr-isis-srv6-extensions

Ketan,

Based on current documents, allocating all SRv6 locators used in a domain from 
a single block is optional.

However, assuming for the moment that a network operator has chosen to allocate 
all SRv6 locators used in a domain from a single block, so that there is a 
well-defined value of B and N across a domain, what is the use of having a 
router advertise its own understanding of these two values?  And what is a 
receiver supposed to do with this information?

Thanks,
Chris

On Fri, Feb 28, 2020 at 8:23 AM 
mailto:bruno.decra...@orange.com>> wrote:
Hi Ketan,

Thanks fort the follow up.
Clarification inline [Bruno]

From: Ketan Talaulikar (ketant) 
[mailto:ket...@cisco.com<mailto:ket...@cisco.com>]
Sent: Friday, February 28, 2020 11:11 AM
To: DECRAENE Bruno TGI/OLN; Ketan Talaulikar (ketant); Chris Bowers
Cc: lsr@ietf.org<mailto:lsr@ietf.org>; SPRING WG List; 
draft-ietf-spring-srv6-network-programming; Peter Psenak (ppsenak)
Subject: RE: [Lsr] clarification of locator block and locator node in 
draft-ietf-spring-srv6-network-programming and 
draft-ietf-lsr-isis-srv6-extensions

Hi Bruno,

I believe the description and usage of Locator is very well described and 
covered in the net-pgm draft as also the corresponding IGP extensions. Is the 
question is more about the “block” part of it (what is not in the block part is 
in the node part as per the text in the net-pgm draft)?

The “block” is again not a new thing. Please check the following:
Under 
https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-26#section-5 
… look for “block”
https://tools.ietf.org/html/rfc8402#section-2 … look under SRGB for SRv6

[Bruno]
To clarify, my question was not specific to “block” but related to the usage, 
by the receiver, of the following piece of information:

  LB Length: SRv6 SID Locator Block length
  LN Length: SRv6 SID Locator Node length
  Fun. Length: SRv6 SID Function length
  Arg. Length: SRv6 SID Arguments length


So perhaps I don’t get Chris’s point and would wait for him to clarify.
[Bruno] I’ll leave this to Chris.

Thanks,
Ketan

From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of 
bruno.decra...@orange.com<mailto:bruno.decra...@orange.com>
Sent: 28 February 2020 14:34
To: Ketan Talaulikar (ketant) 
mailto:40cisco@dmarc.ietf.org>>; Chris 
Bowers mailto:chrisbowers.i...@gmail.com>>
Cc: lsr@ietf.org<mailto:lsr@ietf.org>; SPRING WG List 
mailto:spr...@ietf.org>>; 
draft-ietf-spring-srv6-network-programming 
mailto:draft-ietf-spring-srv6-network-programm...@ietf.org>>;
 Peter Psenak (ppsenak) mailto:ppse...@cisco.com>>
Subject: Re: [Lsr] clarification of locator block and locator node in 
draft-ietf-spring-srv6-network-programming and 
draft-ietf-lsr-isis-srv6-extensions

Hi Ketan,



From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Ketan Talaulikar (ketant)
Sent: Friday, February 28, 2020 6:30 AM

Hi Chris,

I agree with Peter and I would suggest to drop LSR since this is not a protocol 
specific thing.

I believe the text in draft-ietf-spring-srv6-network-programming clears says 
what locator block and locator node are. What more details do you think are 
required?

[Bruno] Speaking as an individual, the draft could possibly clarify the usage 
of these information/fields by the receiver. Possibly using the same name/term 
(e.g. SRv6 SID Locator Block length) to ease the references between both drafts.

Thanks,
--Bruno

Thanks,
Ketan

From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of 
Chris Bowers
Sent: 27 February 2020 22:46
To: lsr@ietf.org<mailto:lsr@ietf.org>; SPRING WG List 
mailto:spr...@ietf.org>>
Cc: Peter Psenak (ppsenak) mailto:ppse...@

Re: [Lsr] clarification of locator block and locator node in draft-ietf-spring-srv6-network-programming and draft-ietf-lsr-isis-srv6-extensions

[Ketan Talaulikar (ketant)]

Hi Bruno,

I believe the description and usage of Locator is very well described and 
covered in the net-pgm draft as also the corresponding IGP extensions. Is the 
question is more about the “block” part of it (what is not in the block part is 
in the node part as per the text in the net-pgm draft)?

The “block” is again not a new thing. Please check the following:
Under 
https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-26#section-5 
… look for “block”
https://tools.ietf.org/html/rfc8402#section-2 … look under SRGB for SRv6

So perhaps I don’t get Chris’s point and would wait for him to clarify.

Thanks,
Ketan

From: Lsr  On Behalf Of bruno.decra...@orange.com
Sent: 28 February 2020 14:34
To: Ketan Talaulikar (ketant) ; Chris Bowers 

Cc: lsr@ietf.org; SPRING WG List ; 
draft-ietf-spring-srv6-network-programming 
; Peter Psenak (ppsenak) 

Subject: Re: [Lsr] clarification of locator block and locator node in 
draft-ietf-spring-srv6-network-programming and 
draft-ietf-lsr-isis-srv6-extensions

Hi Ketan,



From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Ketan Talaulikar (ketant)
Sent: Friday, February 28, 2020 6:30 AM


Hi Chris,

I agree with Peter and I would suggest to drop LSR since this is not a protocol 
specific thing.

I believe the text in draft-ietf-spring-srv6-network-programming clears says 
what locator block and locator node are. What more details do you think are 
required?

[Bruno] Speaking as an individual, the draft could possibly clarify the usage 
of these information/fields by the receiver. Possibly using the same name/term 
(e.g. SRv6 SID Locator Block length) to ease the references between both drafts.

Thanks,
--Bruno

Thanks,
Ketan

From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of 
Chris Bowers
Sent: 27 February 2020 22:46
To: lsr@ietf.org<mailto:lsr@ietf.org>; SPRING WG List 
mailto:spr...@ietf.org>>
Cc: Peter Psenak (ppsenak) mailto:ppse...@cisco.com>>
Subject: [Lsr] clarification of locator block and locator node in 
draft-ietf-spring-srv6-network-programming and 
draft-ietf-lsr-isis-srv6-extensions

SPRING and LSR WGs,

I think that we need a much more detailed description of the locator block and 
locator node in either draft-ietf-spring-srv6-network-programming or 
draft-ietf-lsr-isis-srv6-extensions.  See original email below.

Thanks,
Chris

On Thu, Feb 27, 2020 at 11:08 AM Peter Psenak 
mailto:ppse...@cisco.com>> wrote:
Hi Chris,

On 27/02/2020 17:54, Chris Bowers wrote:
> LSR WG,
>
> Section 9 of draft-ietf-lsr-isis-srv6-extensions-05 defines the  SRv6
> SID Structure Sub-Sub-TLV. In particular, it defines encoding for the
> locator block length and the locator node length.  The text refers to
> [I-D.ietf-spring-srv6-network-programming] for the definition of these
> concepts.
>
> As far as I can tell, the only reference to locator block and locator
> node in draft-ietf-spring-srv6-network-programming-10 is section 3.1
> which has the following text:
>
> A locator may be represented as B:N where B is the SRv6 SID block
> (IPv6 subnet allocated for SRv6 SIDs by the operator) and N is the
> identifier of the parent node instantiating the SID..
>
> I think that we need a much more detailed description of the locator
> block and locator node.

sure, but that would be in the
draft-ietf-spring-srv6-network-programming-10, not in
draft-ietf-lsr-isis-srv6-extensions, as these are not a protocol
specific constructs.

thanks,
Peter

>
> Thanks,
>
> Chris
>

_



Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.



This message and its attachments may contain confidential or privileged 
information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete 
this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.

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

Re: [Lsr] clarification of locator block and locator node in draft-ietf-spring-srv6-network-programming and draft-ietf-lsr-isis-srv6-extensions

[Ketan Talaulikar (ketant)]

Hi Chris,

I agree with Peter and I would suggest to drop LSR since this is not a protocol 
specific thing.

I believe the text in draft-ietf-spring-srv6-network-programming clears says 
what locator block and locator node are. What more details do you think are 
required?

Thanks,
Ketan

From: Lsr  On Behalf Of Chris Bowers
Sent: 27 February 2020 22:46
To: lsr@ietf.org; SPRING WG List 
Cc: Peter Psenak (ppsenak) 
Subject: [Lsr] clarification of locator block and locator node in 
draft-ietf-spring-srv6-network-programming and 
draft-ietf-lsr-isis-srv6-extensions

SPRING and LSR WGs,

I think that we need a much more detailed description of the locator block and 
locator node in either draft-ietf-spring-srv6-network-programming or 
draft-ietf-lsr-isis-srv6-extensions.  See original email below.

Thanks,
Chris

On Thu, Feb 27, 2020 at 11:08 AM Peter Psenak 
mailto:ppse...@cisco.com>> wrote:
Hi Chris,

On 27/02/2020 17:54, Chris Bowers wrote:
> LSR WG,
>
> Section 9 of draft-ietf-lsr-isis-srv6-extensions-05 defines the  SRv6
> SID Structure Sub-Sub-TLV. In particular, it defines encoding for the
> locator block length and the locator node length.  The text refers to
> [I-D.ietf-spring-srv6-network-programming] for the definition of these
> concepts.
>
> As far as I can tell, the only reference to locator block and locator
> node in draft-ietf-spring-srv6-network-programming-10 is section 3.1
> which has the following text:
>
> A locator may be represented as B:N where B is the SRv6 SID block
> (IPv6 subnet allocated for SRv6 SIDs by the operator) and N is the
> identifier of the parent node instantiating the SID..
>
> I think that we need a much more detailed description of the locator
> block and locator node.

sure, but that would be in the
draft-ietf-spring-srv6-network-programming-10, not in
draft-ietf-lsr-isis-srv6-extensions, as these are not a protocol
specific constructs.

thanks,
Peter

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

Re: [Lsr] WG Adoption Call for draft-li-lsr-ospfv3-srv6-extensions

[Ketan Talaulikar (ketant)]

Hi Chris/Acee,

The WG version of the draft has just been posted. It also includes the changes 
for the comments received during the adoption as discussed on the mailing list.

Thanks,
Ketan (on behalf of co-authors)

-Original Message-
From: Christian Hopps  
Sent: 12 February 2020 16:42
To: lsr@ietf.org
Cc: Christian Hopps ; 
draft-li-lsr-ospfv3-srv6-extensi...@ietf.org; lsr-...@ietf.org; Acee Lindem 
(acee) 
Subject: Re: [Lsr] WG Adoption Call for draft-li-lsr-ospfv3-srv6-extensions

The document is adopted.

Authors, please repost as draft-ietf-lsr-ospfv3-srv6-extensions.

Thanks,
Chris & Acee.

> On Jan 23, 2020, at 3:24 PM, Christian Hopps  wrote:
> 
> Hi LSR WG and Draft Authors,
> 
> The authors originally requested adoption back @ 105; however, some comments 
> were received and new version was produced. Moving forward...
> 
> This begins a 2 week WG adoption poll for the following draft:
> 
>  https://datatracker.ietf.org/doc/draft-li-lsr-ospfv3-srv6-extensions/
> 
> Please indicate your support or objection by Feb 6, 2020.
> 
> Authors, please respond indicating whether you are aware of any IPR that 
> applies to this draft.
> 
> Thanks,
> Chris & 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] WG Adoption Call for draft-li-lsr-ospfv3-srv6-extensions

[Ketan Talaulikar (ketant)]

Thanks Acee. Your proposed text looks much better.

Thanks,
Ketan

-Original Message-
From: Acee Lindem (acee)  
Sent: 31 January 2020 18:02
To: Ketan Talaulikar (ketant) ; Peter Psenak (ppsenak) 
; li_zhenqi...@hotmail.com; Christian Hopps 
; lsr 
Cc: draft-li-lsr-ospfv3-srv6-extensions 
; lsr-ads 
Subject: Re: [Lsr] WG Adoption Call for draft-li-lsr-ospfv3-srv6-extensions

Hey Ketan, 

Looks good - but can we simplify/shorten the last sentence?


On 1/31/20, 7:22 AM, "Ketan Talaulikar (ketant)"  wrote:

Hi Acee,

We'll update the text as follows in sec 8 to clarify this. Please let know 
if this works.


   All End.X SIDs MUST be subsumed by the subnet of a Locator with the
   matching algorithm which is advertised by the same node in an SRv6
   Locator TLV.  End.X SIDs which do not meet this requirement MUST be
   ignored.



   All End.X and LAN End.X SIDs MUST be subsumed by the subnet of a 
   Locator with the matching algorithm which is advertised by the same 
   node in an SRv6 Locator TLV.  End.X SIDs which do not meet this 
   requirement MUST be ignored. This ensures that the node
   advertising the End.X or LAN End.X SID is also advertising its
   corresponding Locator with matching algorithm that would be used
   for routing packets destined to that SID to its parent node 
   consistently over the specific algorithm topology. 


How about  "... with the algorithm that will be used for computing paths 
destined to the SID."? 

Do we refer to "specific algorithm topologies" in the flex algorithm draft? I 
haven't read it for a while... 

Thanks,
Acee


Thanks,
Ketan

-Original Message-
From: Acee Lindem (acee)  
Sent: 30 January 2020 23:02
    To: Peter Psenak (ppsenak) ; Ketan Talaulikar (ketant) 
; li_zhenqi...@hotmail.com; Christian Hopps 
; lsr 
Cc: draft-li-lsr-ospfv3-srv6-extensions 
; lsr-ads 
Subject: Re: [Lsr] WG Adoption Call for draft-li-lsr-ospfv3-srv6-extensions

Hi Peter, 

On 1/30/20, 12:25 PM, "Peter Psenak"  wrote:

Hi Acee,

On 30/01/2020 18:12, Acee Lindem (acee) wrote:
> Hi Peter,
> 
> On 1/30/20, 11:36 AM, "Peter Psenak"  wrote:
> 
>  Hi Acee,
>  
>  On 30/01/2020 17:11, Acee Lindem (acee) wrote:
>  > Hi Ketan,
>  >
>  > In that case, it doesn’t make sense to include it in the End.X
>  > advertisement since you need to look it up to check it anyway. 
I don’t
>  > see any benefit here.
>  The benefit is to make sure that the END.X SID that was 
configured for
>  the algo X is covered by the locator that has the same algo.
>  
>  If you do not advertise the algo with END.X SID, you have no way 
of
>  checking that on rcv side.
> 
> Ok - so it is to verify that algorithm for the adjacency matches that 
algorithm for the longest match locator - which may be advertised by a 
>different OSPFv3 router. Correct? 

yes.


>I guess I don't see why the algorithm for the END.X SID just isn't 
defined as the algorithm from the longest match locator. That way, everyone in 
>the area would use the same one and there would be less that could go wrong. 
What am I missing?

locators may change over time. During the reconfiguration a END.X SID 
may wrongly be associated with the incorrect locator from a different 
algo.

Also if for some reason the right locator is not advertised (due to a 
bug on the originator), END.X SID traffic may be sent using a wrong 
algo. We wanted to avoid it as that can be seen as a security issue.

Ok - makes sense. It would be good to capture these reasons in the along 
with the test for ignoring END.X SIDs that have conflicting algorithms with 
their longest matching locator. 

thanks,
Peter



> 
> Thanks,
> Acee
> 
>  
>  thanks,
>  Peter
    >  
>  >
>  > Thanks,
>  >
>  > Acee
>  >
>  > *From: *"Ketan Talaulikar (ketant)" 
>  > *Date: *Thursday, January 30, 2020 at 11:06 AM
>  > *To: *Acee Lindem , "li_zhenqi...@hotmail.com"
>  > , Christian Hopps 
, lsr
>  > 
>  > *Cc: *draft-li-lsr-ospfv3-srv6-extensions
>  > , lsr-ads 

>  > *Subject: *RE: [

Re: [Lsr] WG Adoption Call for draft-li-lsr-ospfv3-srv6-extensions

[Ketan Talaulikar (ketant)]

Hi Acee,

We'll update the text as follows in sec 8 to clarify this. Please let know if 
this works.


   All End.X SIDs MUST be subsumed by the subnet of a Locator with the
   matching algorithm which is advertised by the same node in an SRv6
   Locator TLV.  End.X SIDs which do not meet this requirement MUST be
   ignored.



   All End.X and LAN End.X SIDs MUST be subsumed by the subnet of a 
   Locator with the matching algorithm which is advertised by the same 
   node in an SRv6 Locator TLV.  End.X SIDs which do not meet this 
   requirement MUST be ignored. This ensures that the node
   advertising the End.X or LAN End.X SID is also advertising its
   corresponding Locator with matching algorithm that would be used
   for routing packets destined to that SID to its parent node 
   consistently over the specific algorithm topology. 


Thanks,
Ketan

-Original Message-
From: Acee Lindem (acee)  
Sent: 30 January 2020 23:02
To: Peter Psenak (ppsenak) ; Ketan Talaulikar (ketant) 
; li_zhenqi...@hotmail.com; Christian Hopps 
; lsr 
Cc: draft-li-lsr-ospfv3-srv6-extensions 
; lsr-ads 
Subject: Re: [Lsr] WG Adoption Call for draft-li-lsr-ospfv3-srv6-extensions

Hi Peter, 

On 1/30/20, 12:25 PM, "Peter Psenak"  wrote:

Hi Acee,

On 30/01/2020 18:12, Acee Lindem (acee) wrote:
> Hi Peter,
> 
> On 1/30/20, 11:36 AM, "Peter Psenak"  wrote:
> 
>  Hi Acee,
>  
>  On 30/01/2020 17:11, Acee Lindem (acee) wrote:
>  > Hi Ketan,
>  >
>  > In that case, it doesn’t make sense to include it in the End.X
>  > advertisement since you need to look it up to check it anyway. I 
don’t
>  > see any benefit here.
>  The benefit is to make sure that the END.X SID that was configured 
for
>  the algo X is covered by the locator that has the same algo.
>  
>  If you do not advertise the algo with END.X SID, you have no way of
>  checking that on rcv side.
> 
> Ok - so it is to verify that algorithm for the adjacency matches that 
algorithm for the longest match locator - which may be advertised by a 
>different OSPFv3 router. Correct? 

yes.


>I guess I don't see why the algorithm for the END.X SID just isn't defined 
as the algorithm from the longest match locator. That way, everyone in >the 
area would use the same one and there would be less that could go wrong. What 
am I missing?

locators may change over time. During the reconfiguration a END.X SID 
may wrongly be associated with the incorrect locator from a different algo.

Also if for some reason the right locator is not advertised (due to a 
bug on the originator), END.X SID traffic may be sent using a wrong 
algo. We wanted to avoid it as that can be seen as a security issue.

Ok - makes sense. It would be good to capture these reasons in the along with 
the test for ignoring END.X SIDs that have conflicting algorithms with their 
longest matching locator. 

thanks,
Peter



> 
> Thanks,
> Acee
> 
>  
>  thanks,
>  Peter
>  
>  >
>  > Thanks,
>  >
>  > Acee
>  >
>  > *From: *"Ketan Talaulikar (ketant)" 
>  > *Date: *Thursday, January 30, 2020 at 11:06 AM
>  > *To: *Acee Lindem , "li_zhenqi...@hotmail.com"
>  > , Christian Hopps , 
lsr
>  > 
>  > *Cc: *draft-li-lsr-ospfv3-srv6-extensions
>  > , lsr-ads 

>  > *Subject: *RE: [Lsr] WG Adoption Call for
>  > draft-li-lsr-ospfv3-srv6-extensions
>  >
>  > Hi Acee/Zhen,
>  >
>  > The sec 8 of the draft has the following text which specifies the
>  > handling of this condition.
>  >
>  > All End.X SIDs MUST be subsumed by the subnet of a Locator 
with the
>  >
>  > matching algorithm which is advertised by the same node in an 
SRv6
>  >
>  > Locator TLV.  End.X SIDs which do not meet this requirement 
MUST be
>  >
>  > ignored.
>  >
>  > Thanks,
>  >
>  > Ketan
>  >
>  > *From:* Acee Lindem (acee) 
>  > *Sent:* 30 January 2020 21:01
>  > *To:* li_zhenqi...@hotmail.com; Ketan Talaulikar (ketant)
>  > ; Christian Hopps ; lsr 

>  > *Cc:* draft-li-lsr-ospfv3-srv6-extensions
>  > ; lsr-ads 

>  > *Subject:* Re: [Lsr] WG Adoption Call for
>  >

Re: [Lsr] WG Adoption Call for draft-li-lsr-ospfv3-srv6-extensions

[Ketan Talaulikar (ketant)]

Hi Acee/Zhen,

The sec 8 of the draft has the following text which specifies the handling of 
this condition.

   All End.X SIDs MUST be subsumed by the subnet of a Locator with the
   matching algorithm which is advertised by the same node in an SRv6
   Locator TLV.  End.X SIDs which do not meet this requirement MUST be
   ignored.

Thanks,
Ketan

From: Acee Lindem (acee) 
Sent: 30 January 2020 21:01
To: li_zhenqi...@hotmail.com; Ketan Talaulikar (ketant) ; 
Christian Hopps ; lsr 
Cc: draft-li-lsr-ospfv3-srv6-extensions 
; lsr-ads 
Subject: Re: [Lsr] WG Adoption Call for draft-li-lsr-ospfv3-srv6-extensions

Hi Ketan, Zhen,

What happens if there an algorithm conflict between the Adjacency END.X SID and 
the longest match Locator SID? Either one has to take precedence or this is an 
error condition. In either case, it needs to be documented.
Thanks,
Acee

From: "li_zhenqi...@hotmail.com<mailto:li_zhenqi...@hotmail.com>" 
mailto:li_zhenqi...@hotmail.com>>
Date: Thursday, January 30, 2020 at 10:20 AM
To: "Ketan Talaulikar (ketant)" mailto:ket...@cisco.com>>, 
Christian Hopps mailto:cho...@chopps.org>>, lsr 
mailto:lsr@ietf.org>>
Cc: draft-li-lsr-ospfv3-srv6-extensions 
mailto:draft-li-lsr-ospfv3-srv6-extensi...@ietf.org>>,
 lsr-ads mailto:lsr-...@ietf.org>>, Christian Hopps 
mailto:cho...@chopps.org>>, Acee Lindem 
mailto:a...@cisco.com>>
Subject: Re: RE: [Lsr] WG Adoption Call for draft-li-lsr-ospfv3-srv6-extensions

For the third concern, I think it is better to list the considerations behind 
the format design of the TLVs to help readers understand them better. For the 
specification behavior you mention, this doc SHOULD specify it explicitly.
By the way, what a router should do when it receives END.X SID containing 
algorithm that is different from the one carried in the convering locator?

Best Regards,
Zhenqiang Li
____
li_zhenqi...@hotmail.com<mailto:li_zhenqi...@hotmail.com>

From: Ketan Talaulikar (ketant)<mailto:ket...@cisco.com>
Date: 2020-01-30 16:44
To: li_zhenqi...@hotmail.com<mailto:li_zhenqi...@hotmail.com>; Christian 
Hopps<mailto:cho...@chopps.org>; lsr<mailto:lsr@ietf.org>
CC: 
draft-li-lsr-ospfv3-srv6-extensions<mailto:draft-li-lsr-ospfv3-srv6-extensi...@ietf.org>;
 lsr-ads<mailto:lsr-...@ietf.org>; Christian Hopps<mailto:cho...@chopps.org>; 
Acee Lindem (acee)<mailto:a...@cisco.com>
Subject: RE: RE: [Lsr] WG Adoption Call for draft-li-lsr-ospfv3-srv6-extensions
Please check inline again.

From: li_zhenqi...@hotmail.com<mailto:li_zhenqi...@hotmail.com> 
mailto:li_zhenqi...@hotmail.com>>
Sent: 30 January 2020 13:46
To: Ketan Talaulikar (ketant) mailto:ket...@cisco.com>>; 
Christian Hopps mailto:cho...@chopps.org>>; lsr 
mailto:lsr@ietf.org>>
Cc: draft-li-lsr-ospfv3-srv6-extensions 
mailto:draft-li-lsr-ospfv3-srv6-extensi...@ietf.org>>;
 lsr-ads mailto:lsr-...@ietf.org>>; Christian Hopps 
mailto:cho...@chopps.org>>; Acee Lindem (acee) 
mailto:a...@cisco.com>>
Subject: Re: RE: [Lsr] WG Adoption Call for draft-li-lsr-ospfv3-srv6-extensions

Thank you KT for your quick response. Please see my reply begins with [ZQ].

Best Regards,
Zhenqiang Li

li_zhenqi...@hotmail.com<mailto:li_zhenqi...@hotmail.com>

From: Ketan Talaulikar (ketant)<mailto:ket...@cisco.com>
Date: 2020-01-30 13:42
To: li_zhenqi...@hotmail.com<mailto:li_zhenqi...@hotmail.com>; Christian 
Hopps<mailto:cho...@chopps.org>; lsr<mailto:lsr@ietf.org>
CC: 
draft-li-lsr-ospfv3-srv6-extensions<mailto:draft-li-lsr-ospfv3-srv6-extensi...@ietf.org>;
 lsr-ads<mailto:lsr-...@ietf.org>; Christian Hopps<mailto:cho...@chopps.org>; 
Acee Lindem (acee)<mailto:a...@cisco.com>
Subject: RE: [Lsr] WG Adoption Call for draft-li-lsr-ospfv3-srv6-extensions
Hello Zhenqiang Li,

Thanks for your review and comments. Please check inline below.

From: li_zhenqi...@hotmail.com<mailto:li_zhenqi...@hotmail.com> 
mailto:li_zhenqi...@hotmail.com>>
Sent: 30 January 2020 08:46
To: Christian Hopps mailto:cho...@chopps.org>>; lsr 
mailto:lsr@ietf.org>>
Cc: draft-li-lsr-ospfv3-srv6-extensions 
mailto:draft-li-lsr-ospfv3-srv6-extensi...@ietf.org>>;
 lsr-ads mailto:lsr-...@ietf.org>>; Christian Hopps 
mailto:cho...@chopps.org>>; Acee Lindem (acee) 
mailto:a...@cisco.com>>
Subject: Re: [Lsr] WG Adoption Call for draft-li-lsr-ospfv3-srv6-extensions

support the adoption with the following comments.

1. What does SRH stack mean in section 4.2? AS specified in RFC8200 and 
draft-ietf-6man-segment-routing-header, only one SRH can be presented in one 
IPv6 header.

[KT] Thanks for catching this error and will fix as below:


OLD: The Maximum End Pop MSD Type specifies the maximum number of SIDs in
   the top SRH in an SRH stack to whic

Re: [Lsr] WG Adoption Call for draft-li-lsr-ospfv3-srv6-extensions

[Ketan Talaulikar (ketant)]

Please check inline again.

From: li_zhenqi...@hotmail.com 
Sent: 30 January 2020 13:46
To: Ketan Talaulikar (ketant) ; Christian Hopps 
; lsr 
Cc: draft-li-lsr-ospfv3-srv6-extensions 
; lsr-ads ; 
Christian Hopps ; Acee Lindem (acee) 
Subject: Re: RE: [Lsr] WG Adoption Call for draft-li-lsr-ospfv3-srv6-extensions

Thank you KT for your quick response. Please see my reply begins with [ZQ].

Best Regards,
Zhenqiang Li

li_zhenqi...@hotmail.com<mailto:li_zhenqi...@hotmail.com>

From: Ketan Talaulikar (ketant)<mailto:ket...@cisco.com>
Date: 2020-01-30 13:42
To: li_zhenqi...@hotmail.com<mailto:li_zhenqi...@hotmail.com>; Christian 
Hopps<mailto:cho...@chopps.org>; lsr<mailto:lsr@ietf.org>
CC: 
draft-li-lsr-ospfv3-srv6-extensions<mailto:draft-li-lsr-ospfv3-srv6-extensi...@ietf.org>;
 lsr-ads<mailto:lsr-...@ietf.org>; Christian Hopps<mailto:cho...@chopps.org>; 
Acee Lindem (acee)<mailto:a...@cisco.com>
Subject: RE: [Lsr] WG Adoption Call for draft-li-lsr-ospfv3-srv6-extensions
Hello Zhenqiang Li,

Thanks for your review and comments. Please check inline below.

From: li_zhenqi...@hotmail.com<mailto:li_zhenqi...@hotmail.com> 
mailto:li_zhenqi...@hotmail.com>>
Sent: 30 January 2020 08:46
To: Christian Hopps mailto:cho...@chopps.org>>; lsr 
mailto:lsr@ietf.org>>
Cc: draft-li-lsr-ospfv3-srv6-extensions 
mailto:draft-li-lsr-ospfv3-srv6-extensi...@ietf.org>>;
 lsr-ads mailto:lsr-...@ietf.org>>; Christian Hopps 
mailto:cho...@chopps.org>>; Acee Lindem (acee) 
mailto:a...@cisco.com>>
Subject: Re: [Lsr] WG Adoption Call for draft-li-lsr-ospfv3-srv6-extensions

support the adoption with the following comments.

1. What does SRH stack mean in section 4.2? AS specified in RFC8200 and 
draft-ietf-6man-segment-routing-header, only one SRH can be presented in one 
IPv6 header.

[KT] Thanks for catching this error and will fix as below:


OLD: The Maximum End Pop MSD Type specifies the maximum number of SIDs in
   the top SRH in an SRH stack to which the router can apply Penultimate
   Segment Pop (PSP) or Ultimate Segment Pop (USP)


NEW: The Maximum End Pop MSD Type specifies the maximum number of SIDs in

   the SRH for which the router can apply Penultimate

   Segment Pop (PSP) or Ultimate Segment Pop (USP)


[ZQ] Fine.

2. The abbreviations used in this draft should be listed in a seperated section 
or point out where they are defined.
[KT] We’ve followed the convention of expanding on first use as also providing 
reference where necessary. Please do let know if we’ve missed doing so anywhere.

[ZQ] Some examples: SPF computation in secction 5,  TBD in section 2.
[KT] Will expand SPF and some other such on first use :-). The TBD (to be 
decided) is for use until the code point are allocated by IANA.

3. Algorithm field is defined for End.x SID to carry the algorithm the end.x 
sid associates. But no algorithm field is defined for End SID in section 7. May 
I know the reason?
[KT] The SRv6 Locator TLV that is the parent of the SRv6 End SID Sub-TLV 
carries the algorithm and hence there is no need to repeat in the Sub-TLV. This 
is not the case for SRv6 End.X SID Sub-TLV and hence it has the algorithm field.


[ZQ] Make sense but still a little bit weird. Since any SID belongs to a 
locator, or it is not routable, the algorithm field in the end.x sid is not 
needed, end.x sid associates the algorithm carried in the corresponding locator 
tlv.

[KT] Having an algorithm field advertised with the End.X SID makes it easier 
for implementation to find the algorithm specific End.X SID without making the 
longest prefix match on all locators advertised by the node to find the 
algorithm to which the SID belongs. It also makes it possible to verify that 
the algorithm associated with the End.X SID matches that of the covering 
Locator when the link advertisement with End.X SID is received.



Thanks,

Ketan

Thanks,
Ketan

Best Regards,
Zhenqiang Li

li_zhenqi...@hotmail.com<mailto:li_zhenqi...@hotmail.com>

From: Christian Hopps<mailto:cho...@chopps.org>
Date: 2020-01-24 04:24
To: lsr<mailto:lsr@ietf.org>
CC: 
draft-li-lsr-ospfv3-srv6-extensions<mailto:draft-li-lsr-ospfv3-srv6-extensi...@ietf.org>;
 lsr-ads<mailto:lsr-...@ietf.org>; Christian Hopps<mailto:cho...@chopps.org>; 
Acee Lindem \(acee\)<mailto:a...@cisco.com>
Subject: [Lsr] WG Adoption Call for draft-li-lsr-ospfv3-srv6-extensions
Hi LSR WG and Draft Authors,

The authors originally requested adoption back @ 105; however, some comments 
were received and new version was produced. Moving forward...

This begins a 2 week WG adoption poll for the following draft:

  https://datatracker.ietf.org/doc/draft-li-lsr-ospfv3-srv6-extensions/
Please indicate your support or objection by Feb 6, 2020.

Authors, please respond indicating whether you are aware of any IPR that 

Re: [Lsr] WG Adoption Call for draft-li-lsr-ospfv3-srv6-extensions

[Ketan Talaulikar (ketant)]

Hello Zhenqiang Li,

Thanks for your review and comments. Please check inline below.

From: li_zhenqi...@hotmail.com 
Sent: 30 January 2020 08:46
To: Christian Hopps ; lsr 
Cc: draft-li-lsr-ospfv3-srv6-extensions 
; lsr-ads ; 
Christian Hopps ; Acee Lindem (acee) 
Subject: Re: [Lsr] WG Adoption Call for draft-li-lsr-ospfv3-srv6-extensions

support the adoption with the following comments.

1. What does SRH stack mean in section 4.2? AS specified in RFC8200 and 
draft-ietf-6man-segment-routing-header, only one SRH can be presented in one 
IPv6 header.

[KT] Thanks for catching this error and will fix as below:


OLD: The Maximum End Pop MSD Type specifies the maximum number of SIDs in
   the top SRH in an SRH stack to which the router can apply Penultimate
   Segment Pop (PSP) or Ultimate Segment Pop (USP)


NEW: The Maximum End Pop MSD Type specifies the maximum number of SIDs in

   the SRH for which the router can apply Penultimate

   Segment Pop (PSP) or Ultimate Segment Pop (USP)

2. The abbreviations used in this draft should be listed in a seperated section 
or point out where they are defined.
[KT] We've followed the convention of expanding on first use as also providing 
reference where necessary. Please do let know if we've missed doing so anywhere.

3. Algorithm field is defined for End.x SID to carry the algorithm the end.x 
sid associates. But no algorithm field is defined for End SID in section 7. May 
I know the reason?
[KT] The SRv6 Locator TLV that is the parent of the SRv6 End SID Sub-TLV 
carries the algorithm and hence there is no need to repeat in the Sub-TLV. This 
is not the case for SRv6 End.X SID Sub-TLV and hence it has the algorithm field.

Thanks,
Ketan

Best Regards,
Zhenqiang Li

li_zhenqi...@hotmail.com

From: Christian Hopps
Date: 2020-01-24 04:24
To: lsr
CC: 
draft-li-lsr-ospfv3-srv6-extensions;
 lsr-ads; Christian Hopps; 
Acee Lindem \(acee\)
Subject: [Lsr] WG Adoption Call for draft-li-lsr-ospfv3-srv6-extensions
Hi LSR WG and Draft Authors,

The authors originally requested adoption back @ 105; however, some comments 
were received and new version was produced. Moving forward...

This begins a 2 week WG adoption poll for the following draft:

  https://datatracker.ietf.org/doc/draft-li-lsr-ospfv3-srv6-extensions/
Please indicate your support or objection by Feb 6, 2020.

Authors, please respond indicating whether you are aware of any IPR that 
applies to this draft.

Thanks,
Chris & 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] WG Adoption Call for draft-li-lsr-ospfv3-srv6-extensions

[Ketan Talaulikar (ketant)]

Hi All,

Support the draft as a co-author and I am not aware of any IPR other than what 
has been disclosed on this draft.

Thanks,
Ketan

-Original Message-
From: Christian Hopps  
Sent: 24 January 2020 01:55
To: lsr@ietf.org
Cc: Christian Hopps ; Acee Lindem (acee) ; 
lsr-...@ietf.org; draft-li-lsr-ospfv3-srv6-extensi...@ietf.org
Subject: WG Adoption Call for draft-li-lsr-ospfv3-srv6-extensions

Hi LSR WG and Draft Authors,

The authors originally requested adoption back @ 105; however, some comments 
were received and new version was produced. Moving forward...

This begins a 2 week WG adoption poll for the following draft:

  https://datatracker.ietf.org/doc/draft-li-lsr-ospfv3-srv6-extensions/
 
Please indicate your support or objection by Feb 6, 2020.

Authors, please respond indicating whether you are aware of any IPR that 
applies to this draft.

Thanks,
Chris & Acee.

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

Re: [Lsr] WG Last Call draft-ietf-lsr-isis-srv6-extensions

[Ketan Talaulikar (ketant)]

Support. As a contributor, I am not aware of any undisclosed IPR related to 
this draft.

Thanks,
Ketan

-Original Message-
From: Lsr  On Behalf Of Paul Wells (pauwells)
Sent: 24 January 2020 06:10
To: cho...@chopps.org; lsr@ietf.org
Cc: lsr-...@ietf.org; Acee Lindem (acee) 
Subject: Re: [Lsr] WG Last Call draft-ietf-lsr-isis-srv6-extensions

Support. Not aware of any undisclosed IPR.

Paul

On Tue, 2020-01-21 at 19:14 -0500, Christian Hopps wrote:
> This begins a 2 week WG Last Call, ending after Feb 4, 2020, for 
> draft-ietf-lsr-isis-srv6-extensions
> 
>   https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-srv6-extensions/
> 
> Authors please indicate if you aware of any other IPR beyond what is posted:
> 
>   https://datatracker.ietf.org/ipr/3796/
> 
> Thanks,
> Chris & 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

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

Re: [Lsr] Comments on draft-li-ospf-ospfv3-srv6-extensions-07.txt

[Ketan Talaulikar (ketant)]

Hi Acee,

Thanks for your review, comments and suggestions. We’ve incorporated them and 
posted an update for this draft.

Note that as requested in a separate email thread, the draft has been renamed 
so it is associated with the LSR WG instead of the old OSPF one : 
https://datatracker.ietf.org/doc/draft-li-lsr-ospfv3-srv6-extensions/

This draft also has editorial changes to align with the latest version of the 
draft-ietf-spring-srv6-network-programming and is functionally equivalent to 
the draft-ietf-lsr-isis-srv6-extensions.

The authors believe this version is ready for WG adoption as requested 
previously.

Thanks,
Ketan (on behalf of co-authors)

From: Lizhenbin 
Sent: 16 December 2019 20:31
To: Acee Lindem (acee) ; 
draft-li-ospf-ospfv3-srv6-extensi...@ietf.org
Cc: lsr@ietf.org
Subject: RE: Comments on draft-li-ospf-ospfv3-srv6-extensions-07.txt

Hi Acee,
Thanks very much for your help to refine the draft. You suggestion also makes 
sense. We will update accordingly.

Best Regards,
Robin



From: Acee Lindem (acee) [mailto:a...@cisco.com]
Sent: Friday, December 13, 2019 5:44 AM
To: 
draft-li-ospf-ospfv3-srv6-extensi...@ietf.org
Cc: lsr@ietf.org
Subject: Comments on draft-li-ospf-ospfv3-srv6-extensions-07.txt

Hi Robin, et al,
One thing I’d like to see is incorporation of the text for the MSD types in the 
draft. It is less than one and a half pages and it doesn’t make sense to 
reference the IS-IS draft. I’ve also attached my editorial comments.

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

Re: [Lsr] WG Adoption Call for draft-ketant-lsr-ospf-bfd-strict-mode

[Ketan Talaulikar (ketant)]

Thanks Chris. We've just posted the WG version of this draft that was adopted.

-Original Message-
From: Lsr  On Behalf Of Christian Hopps
Sent: 06 January 2020 23:49
To: lsr@ietf.org
Cc: lsr-...@ietf.org; Christian Hopps ; 
draft-ketant-lsr-ospf-bfd-strict-m...@ietf.org
Subject: Re: [Lsr] WG Adoption Call for draft-ketant-lsr-ospf-bfd-strict-mode

That should be draft-ietf-lsr-ospf-bfd-strict-mode

Thanks,
Chris.

> On Jan 6, 2020, at 1:18 PM, Christian Hopps  wrote:
> 
> The document is adopted.
> 
> Authors, please repost with the name draft-lsr-ospf-bfd-strict-mode-00.
> 
> Thanks,
> Chris & Acee.
> 
>> On Dec 13, 2019, at 6:54 AM, Christian Hopps  wrote:
>> 
>> Hi LSR WG and Draft Authors,
>> 
>> This begins a 2 week WG adoption poll for the following draft:
>> 
>> https://datatracker.ietf.org/doc/draft-ketant-lsr-ospf-bfd-strict-mode/
>> 
>> Please indicate your support or objection by Dec 27th.
>> 
>> Authors, please respond indicating whether you are aware of any IPR that 
>> applies to this draft.
>> 
>> Thanks,
>> Chris & 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
> 

___
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 draft-ketant-lsr-ospf-reverse-metric

[Ketan Talaulikar (ketant)]

Thanks Chris. We've just posted the WG version of this draft that was adopted.

-Original Message-
From: Lsr  On Behalf Of Christian Hopps
Sent: 06 January 2020 23:51
To: lsr@ietf.org
Cc: draft-ketant-lsr-ospf-reverse-met...@ietf.org; lsr-...@ietf.org; Christian 
Hopps 
Subject: Re: [Lsr] WG Adoption Call for draft-ketant-lsr-ospf-reverse-metric

The document is adopted.

Authors, please post a new version with name 
draft-ietf-lsr-ospf-reverse-metric-00.

Thanks,
Chris.

> On Dec 13, 2019, at 6:28 AM, Christian Hopps  wrote:
> 
> Hi LSR WG and Draft Authors,
> 
> This begins a 2 week WG adoption poll for the following draft:
> 
>  https://datatracker.ietf.org/doc/draft-ketant-lsr-ospf-reverse-metric/
> 
> Please indicate your support or objection by Dec 27th.
> 
> Authors, please respond indicating whether you are aware of any IPR that 
> applies to this draft.
> 
> Thanks,
> Chris & 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

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

Re: [Lsr] WG Last Call draft-ietf-lsr-isis-invalid-tlv

[Ketan Talaulikar (ketant)]

Support the publication

-Original Message-
From: Lsr  On Behalf Of Christian Hopps
Sent: 03 January 2020 00:37
To: lsr@ietf.org
Cc: lsr-...@ietf.org; Christian Hopps ; Antoni Przygienda 

Subject: [Lsr] WG Last Call draft-ietf-lsr-isis-invalid-tlv

This begins a 2 week WG Last Call, ending after Jan 16th, 2020, for 
draft-ietf-lsr-isis-invalid-tlv.

  https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-invalid-tlv/

Tony P (other authors already responded during the adoption poll), please 
indicate your knowledge of any IPR related to this work to the list as well.

Thanks,
Chris & 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