Re: [Lsr] Rtg-Dir Last Call review of draft-ietf-lsr-flex-algo

[Les Ginsberg (ginsberg)]

Eric –

Always appreciate the time reviewers put in – so apologies if my response came 
off as an overreaction.

As you understood that OSPF addresses backwards compatibility by ignoring 
unknown TLVs I wanted to emphasize that IS-IS has the same policy.

As regards the section on backwards compatibility, Peter has already suggested 
some text that seems to do what you have suggested. I am sure you will let him 
know if it is adequate.

I do understand that the compatibility concerns have to do with networks where 
some nodes support the new functionality and some don’t. But I think the real 
deployment issue is not “compatibility” but that in order for algo specific 
forwarding to work you must have a connected sub-topology of routers that 
support the desired algo. I would not use the term “compatibility” to describe 
that – but if we understand each other then we can leave it at that.

   Les


From: Eric Gray 
Sent: Tuesday, October 20, 2020 6:39 PM
To: Les Ginsberg (ginsberg) ; rtg-...@ietf.org; 
lsr-cha...@ietf.org
Cc: rtg-...@ietf.org; lsr@ietf.org
Subject: RE: Rtg-Dir Last Call review of draft-ietf-lsr-flex-algo

Les,

  Thanks for your helpful feedback on my minor comments.

  I think you may have misunderstood my comments.

  I do not have concerns about backward compatibility with respect 
to the flex-algo ID.

  What I was making a minor comment on was the dismissive approach 
the draft takes with respect to concerns about backward compatibility.

  It simply says that this draft does not introduce any new 
backward compatibility issues – which, going back to when IDs used to say 
pretty much the same thing about Security, is often not quite good enough.

  I feel the draft would make a better RFC if it said just a bit 
more about why the new TLV(s) and Sub-TLVs do not introduce backward 
compatibility issues.  It could even summarize how the extensions in this draft 
are (or are not) impacted by deployment in an environment where not all routers 
are able to participate in any specific flex-algorithm.

  For example, your own statement about why it is not an issue with 
IS-IS would be a useful addition to the section on backward compatibility.

  Maybe you and others disagree that this is useful, and that’s 
fine with me.

  I am happy to take your word for it about configuration, though I 
suspect that you also missed the point I was making about that specific aspect 
of compatibility of newer nodes (that can participate in a flex-algorithm) with 
others (that cannot – likely including existing and deployed routers).

  This point is not very important, so the authors can address it 
any way they want (including doing nothing at all).

  I see these reviews as an opportunity to improve our work, and 
have no other personal investment in my comments.

--
Eric


From: Les Ginsberg (ginsberg) 
mailto:ginsberg=40cisco@dmarc.ietf.org>>
Sent: Friday, October 16, 2020 3:59 PM
To: Eric Gray mailto:eric.g...@ericsson.com>>; 
rtg-...@ietf.org; 
lsr-cha...@ietf.org
Cc: rtg-...@ietf.org; lsr@ietf.org
Subject: RE: Rtg-Dir Last Call review of draft-ietf-lsr-flex-algo
Importance: High

Eric –

I will let the draft authors respond to the bulk of your comments. But in 
regards to your question/comment:

“I assume (but do not actually know) that a similar situation exists for the 
new ISIS FAD Sub-TLV of the existing TLV Type 242 - i.e. - ISIS presumably has 
well defined handling for sub-TLVs (of at least type 242) that are not 
recognized.  If so, than the new Sub-TLV types defined are also not an issue.”

Indeed, base behavior for the IS-IS protocol as defined in ISO 10589 is to 
ignore unrecognized TLVs - and this extends to unrecognized sub-TLVs as well. 
This is key to the ability to introduce the many extensions that have been 
defined by the plethora of IS-IS RFCs over the last 20+ years.
This point is further discussed in the recently published:

https://www.rfc-editor.org/rfc/rfc8918.html#name-handling-of-disallowed-tlvs

So I think your concerns about backwards compatibility are unwarranted. In 
particular the statement:

“[backwards compatibility] apparently relies on configuration of those routers 
that _do_ support the extensions to address this”

Is not correct.

   Les

From: rtg-dir mailto:rtg-dir-boun...@ietf.org>> On 
Behalf Of Eric Gray
Sent: Friday, October 16, 2020 11:49 AM
To: rtg-...@ietf.org; 
lsr-cha...@ietf.org
Cc: rtg-...@ietf.org; lsr@ietf.org

[Lsr] FW: New Version Notification for draft-wang-lsr-passive-interface-attribute-05.txt

[Aijun Wang]

Hi, LSR experts:

We have updated the draft, according to the discussions in the mail list. The 
main update contents are the followings：
1. Add descriptions in the Introduction part, for the potential usages of the 
passive interface information.
2. Add section "Consideration for flagging passive interface", which compares 
the current possible solutions, based on the discussion on the mail list.
3. Delete the section "Scenario Description" for Inter-AS Domain Scenario, 
emphasize more on the protocol extension itself.

Wish to hear more comments for this update.
Thanks in advance.


Best Regards

Aijun Wang
China Telecom

> -Original Message-
> From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org]
> Sent: Wednesday, October 21, 2020 11:25 AM
> To: Zhibo Hu ; Aijun Wang
> ; Gyan S. Mishra ;
> Gyan Mishra 
> Subject: New Version Notification for
> draft-wang-lsr-passive-interface-attribute-05.txt
> 
> 
> A new version of I-D, draft-wang-lsr-passive-interface-attribute-05.txt
> has been successfully submitted by Aijun Wang and posted to the IETF
> repository.
> 
> Name: draft-wang-lsr-passive-interface-attribute
> Revision: 05
> Title:Passive Interface Attribute
> Document date:2020-10-21
> Group:Individual Submission
> Pages:7
> URL:
> https://www.ietf.org/archive/id/draft-wang-lsr-passive-interface-attribute-05.t
> xt
> Status:
> https://datatracker.ietf.org/doc/draft-wang-lsr-passive-interface-attribute/
> Htmlized:
> https://datatracker.ietf.org/doc/html/draft-wang-lsr-passive-interface-attribut
> e
> Htmlized:
> https://tools.ietf.org/html/draft-wang-lsr-passive-interface-attribute-05
> Diff:
> https://www.ietf.org/rfcdiff?url2=draft-wang-lsr-passive-interface-attribute-05
> 
> Abstract:
>This document describes the mechanism that can be used to
>differentiate the passive interfaces from the normal interfaces
>within ISIS or OSPF domain.
> 
> 
> 
> 
> 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

Re: [Lsr] Rtg-Dir Last Call review of draft-ietf-lsr-flex-algo

[Eric Gray]

Les,

  Thanks for your helpful feedback on my minor comments.

  I think you may have misunderstood my comments.

  I do not have concerns about backward compatibility with respect 
to the flex-algo ID.

  What I was making a minor comment on was the dismissive approach 
the draft takes with respect to concerns about backward compatibility.

  It simply says that this draft does not introduce any new 
backward compatibility issues – which, going back to when IDs used to say 
pretty much the same thing about Security, is often not quite good enough.

  I feel the draft would make a better RFC if it said just a bit 
more about why the new TLV(s) and Sub-TLVs do not introduce backward 
compatibility issues.  It could even summarize how the extensions in this draft 
are (or are not) impacted by deployment in an environment where not all routers 
are able to participate in any specific flex-algorithm.

  For example, your own statement about why it is not an issue with 
IS-IS would be a useful addition to the section on backward compatibility.

  Maybe you and others disagree that this is useful, and that’s 
fine with me.

  I am happy to take your word for it about configuration, though I 
suspect that you also missed the point I was making about that specific aspect 
of compatibility of newer nodes (that can participate in a flex-algorithm) with 
others (that cannot – likely including existing and deployed routers).

  This point is not very important, so the authors can address it 
any way they want (including doing nothing at all).

  I see these reviews as an opportunity to improve our work, and 
have no other personal investment in my comments.

--
Eric


From: Les Ginsberg (ginsberg) 
Sent: Friday, October 16, 2020 3:59 PM
To: Eric Gray ; rtg-...@ietf.org; lsr-cha...@ietf.org
Cc: rtg-...@ietf.org; lsr@ietf.org
Subject: RE: Rtg-Dir Last Call review of draft-ietf-lsr-flex-algo
Importance: High

Eric –

I will let the draft authors respond to the bulk of your comments. But in 
regards to your question/comment:

“I assume (but do not actually know) that a similar situation exists for the 
new ISIS FAD Sub-TLV of the existing TLV Type 242 - i.e. - ISIS presumably has 
well defined handling for sub-TLVs (of at least type 242) that are not 
recognized.  If so, than the new Sub-TLV types defined are also not an issue.”

Indeed, base behavior for the IS-IS protocol as defined in ISO 10589 is to 
ignore unrecognized TLVs - and this extends to unrecognized sub-TLVs as well. 
This is key to the ability to introduce the many extensions that have been 
defined by the plethora of IS-IS RFCs over the last 20+ years.
This point is further discussed in the recently published:

https://www.rfc-editor.org/rfc/rfc8918.html#name-handling-of-disallowed-tlvs

So I think your concerns about backwards compatibility are unwarranted. In 
particular the statement:

“[backwards compatibility] apparently relies on configuration of those routers 
that _do_ support the extensions to address this”

Is not correct.

   Les

From: rtg-dir mailto:rtg-dir-boun...@ietf.org>> On 
Behalf Of Eric Gray
Sent: Friday, October 16, 2020 11:49 AM
To: rtg-...@ietf.org; 
lsr-cha...@ietf.org
Cc: rtg-...@ietf.org; lsr@ietf.org
Subject: [RTG-DIR] Rtg-Dir Last Call review of draft-ietf-lsr-flex-algo


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 
https://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-flex-algo-12.txt



Reviewer: Eric Gray

Review Date: 16 October, 2020

IETF LC End Date: Unknown

Intended Status: Standards Track



Summary:

This document is well organized, relatively easy to read, and probably ready 
for publication, but has one potential minor issue and a very small number of 
NITs that might be considered prior to publication.



Major Issues:

None



Minor Issues:

The statement in section 15 (Backward Compatibility) - "This extension brings 
no new backward compatibil

Re: [Lsr] New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt

[Peter Psenak]

Bruno,

On 20/10/2020 14:47, bruno.decra...@orange.com wrote:

Peter,


From: Peter Psenak [mailto:ppse...@cisco.com]

Bruno,

please see inline:



On 20/10/2020 11:43, bruno.decra...@orange.com wrote:

Peter,


From: Peter Psenak [mailto:ppse...@cisco.com]

Bruno,

On 19/10/2020 18:52, bruno.decra...@orange.com wrote:

Ron, all,

>From a use case standpoint, I have a use case for having both SR-MPLS

and

IP flexalgo in the same network.


>From a protocol standpoint, I think that the functionality could be

equally

met by advertising SR-MPLS SID as per RFC 8667 but using a label 3

(implicit

null) to instruct the LER/LSR to not use a label in the forwarding plane.

(while

still advertising a label in the control plane because we have to).

does not work,


I could provide more explanations, but reading your email, it seems to me

that you understood the proposal.

So it seems to me that the opinion that you really meant is: it works but it

would be an nasty hack.


Regarding "nasty hack" it could be interesting to have a normative

definition. This could prove useful in some other contexts.

BTW, is "max metric" a hack (vs creating a new tlv if you don't want the link

in the IGP SPF), is "implicit null label" a hack. And for BGP, encoding the 
label
in the NLRI...

max-metric does not solve the problem, as you would need a prefix metric
for non 0 algo anyway.


To clarify, my text was not a technical proposal related to that draft. It was 
referring to your email and questioning what exactly was a hack using some 
examples from the past.
But let's forget about this point, at least for the moment.


Coming back to technical comments, note that creating yet another TLV to

carry IP prefix also brings questions that the draft does not answer or even
raise.

- What about the sub-TLVs? Are they shared with the existing registry for

prefix TLV [1] ? Do we want to exclude some? E.g., Prefix Segment Identifier
(we would have two algo fields, two ways to signal SIDs...)

yes, these are details that needs to be addressed, but should not be a
problem. Look at locator TLV in SRv6, very similar concept here.


- for IPv6, the content and meaning of  "ISIS MT IPv6 Flexalgo Prefix

Reachability TLV" is essentially the same than the "SRv6 Locator TLV".

- Only the naming and the ordering of the fields are different.
- Why do we need two TLVs to advertise the same thing (essentially a

Routing Algo)? Duplication means more spec, more code, more features to
implement, more error and bugs. (and it did not took long: the draft defines
the MTID field as 8 bits while RFC 5120 defines it a 12 bits.

well, locator is a construct that is specific to SRv6. Sure you can
advertise the prefix in a locator TLV without any SRv6 specific Sub-TLVs
and achieve the same thing - I have already mentioned that in one of my
responses, but that is again ugly.


So we agree that reusing the SRv6 locator TLV would work and provide the 
functionality. Good.
Now here comes again the "ugly" argument. If it's now becoming a technical 
argument, in my opinion, it's ugly to define two TLVs in order to advertise the same 
information and to provide the same functionality.

  

- What is the functional different between FlexAlgo for SRv6 and

FlexAlgo for IPv6? Both use the IPv6 destination address in the packet and
the IPv6 FIB in the router.

they are functionally the same.


Good to agree on this.
  

I believe that having a clean encoding is preferable in a long run.


What do you mean by "clean encoding"? The only differences between both TLVs 
are the naming and the ordering of the fields.


One
can not advertise a prefix as SRv6 locator as well as IP flex-algo
prefix (that would be an error), so duplication of data is not an
issues.


So one should not advertise both TLVs? If so this becomes an error/issue? This 
feels like my point. There is no such issue with a single TLV.


I don't see that error an issue.




And having a dedicated TLV for each is better from both
deployment and implementation perspective.


I can't see how implementing the same functionality twice would be better from 
an implementation perspective, but I leave this to you. I would suspect that 
you may consider only implementing one, not both.


not really, I prefer clean encoding rather the overloading things as we 
extend protocol.



I disagree on the deployment perspective. We would have two TLVs to advertise 
the same information and provide the exactly same functionality.  I can only 
see that this would bring deployment issues. e.g. one vendor implementing TLV A 
while another vendor implementing TLV B; hence no interoperability or a large 
delay to have both vendors implement both TLVs (or at least one vendor 
implementing both, presumably the smaller vendor).


I don't agree. If we keep things clean we would not allow "vendor 
implementing TLV A while another vendor implementing TLV B".


Anyway, it's for the WG to decide what encodi

Re: [Lsr] New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt

[bruno.decraene]

Peter,

> From: Peter Psenak [mailto:ppse...@cisco.com]
> 
> Bruno,
> 
> please see inline:
> 
> 
> 
> On 20/10/2020 11:43, bruno.decra...@orange.com wrote:
> > Peter,
> >
> >> From: Peter Psenak [mailto:ppse...@cisco.com]
> >>
> >> Bruno,
> >>
> >> On 19/10/2020 18:52, bruno.decra...@orange.com wrote:
> >>> Ron, all,
> >>>
> >>> >From a use case standpoint, I have a use case for having both SR-MPLS
> and
> >> IP flexalgo in the same network.
> >>>
> >>> >From a protocol standpoint, I think that the functionality could be
> equally
> >> met by advertising SR-MPLS SID as per RFC 8667 but using a label 3
> (implicit
> >> null) to instruct the LER/LSR to not use a label in the forwarding plane.
> (while
> >> still advertising a label in the control plane because we have to).
> >>
> >> does not work,
> >
> > I could provide more explanations, but reading your email, it seems to me
> that you understood the proposal.
> > So it seems to me that the opinion that you really meant is: it works but it
> would be an nasty hack.
> >
> > Regarding "nasty hack" it could be interesting to have a normative
> definition. This could prove useful in some other contexts.
> > BTW, is "max metric" a hack (vs creating a new tlv if you don't want the 
> > link
> in the IGP SPF), is "implicit null label" a hack. And for BGP, encoding the 
> label
> in the NLRI...
> 
> max-metric does not solve the problem, as you would need a prefix metric
> for non 0 algo anyway.

To clarify, my text was not a technical proposal related to that draft. It was 
referring to your email and questioning what exactly was a hack using some 
examples from the past.
But let's forget about this point, at least for the moment.

> > Coming back to technical comments, note that creating yet another TLV to
> carry IP prefix also brings questions that the draft does not answer or even
> raise.
> > - What about the sub-TLVs? Are they shared with the existing registry for
> prefix TLV [1] ? Do we want to exclude some? E.g., Prefix Segment Identifier
> (we would have two algo fields, two ways to signal SIDs...)
> 
> yes, these are details that needs to be addressed, but should not be a
> problem. Look at locator TLV in SRv6, very similar concept here.
> 
> > - for IPv6, the content and meaning of  "ISIS MT IPv6 Flexalgo Prefix
> Reachability TLV" is essentially the same than the "SRv6 Locator TLV".
> > - Only the naming and the ordering of the fields are different.
> > - Why do we need two TLVs to advertise the same thing (essentially a
> Routing Algo)? Duplication means more spec, more code, more features to
> implement, more error and bugs. (and it did not took long: the draft defines
> the MTID field as 8 bits while RFC 5120 defines it a 12 bits.
> 
> well, locator is a construct that is specific to SRv6. Sure you can
> advertise the prefix in a locator TLV without any SRv6 specific Sub-TLVs
> and achieve the same thing - I have already mentioned that in one of my
> responses, but that is again ugly.

So we agree that reusing the SRv6 locator TLV would work and provide the 
functionality. Good.
Now here comes again the "ugly" argument. If it's now becoming a technical 
argument, in my opinion, it's ugly to define two TLVs in order to advertise the 
same information and to provide the same functionality.

 
> > - What is the functional different between FlexAlgo for SRv6 and
> FlexAlgo for IPv6? Both use the IPv6 destination address in the packet and
> the IPv6 FIB in the router.
> 
> they are functionally the same.

Good to agree on this.
 
> I believe that having a clean encoding is preferable in a long run.

What do you mean by "clean encoding"? The only differences between both TLVs 
are the naming and the ordering of the fields.

> One
> can not advertise a prefix as SRv6 locator as well as IP flex-algo
> prefix (that would be an error), so duplication of data is not an
> issues.

So one should not advertise both TLVs? If so this becomes an error/issue? This 
feels like my point. There is no such issue with a single TLV.

> And having a dedicated TLV for each is better from both
> deployment and implementation perspective.

I can't see how implementing the same functionality twice would be better from 
an implementation perspective, but I leave this to you. I would suspect that 
you may consider only implementing one, not both.
I disagree on the deployment perspective. We would have two TLVs to advertise 
the same information and provide the exactly same functionality.  I can only 
see that this would bring deployment issues. e.g. one vendor implementing TLV A 
while another vendor implementing TLV B; hence no interoperability or a large 
delay to have both vendors implement both TLVs (or at least one vendor 
implementing both, presumably the smaller vendor).

Thanks,
--Bruno
 
> thanks,
> Peter
> 
> 
> 
> 
> >
> > Thanks,
> > Bruno
> >
> >> as it does not allow you to associate the prefix with
> >> Flex-algo without advertising the reachability

Re: [Lsr] draft-xie-lsr-isis-sr-vtn-mt-02

[Xie Chongfeng]

Hi Huaimo,
Thanks for your review and comments. Please see some replies inline:
 

From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Huaimo Chen
Sent: Monday, October 19, 2020 11:09 PM
To: lsr@ietf.org
Subject: [Lsr] draft-xie-lsr-isis-sr-vtn-mt-02
 
Hi Authors,
 
I have the following comments/questions:
 
In a network, can we use other methods to define VTNs while MTs are used as 
VTNs? 
 
[Chongfeng] As described in this document, in some network scenarios, each VTN 
can have an independent topology and a set of dedicated network resources. In a 
network which meets this scenario, using MTs to identify VTNs is a practical 
approach. Other approaches may also be possible, while they are out of the 
scope of this document. Using more than one approach in a network is not 
necessary thus not recommended.
 
If so, other methods may be used to define VTNs in addition to using MTs as 
VTNs in the same network. The draft says that MT-ID could be used as VTN-ID. In 
this case, a block of VTN-IDs must be allocated/reserved specially for using 
MT-IDs as VTN-IDs. It seems better to state something about this in the draft.
 
[Chongfeng] I assume this question is based on the “true” answer to the comment 
above. Since it is considered to only use one approach in a network, and this 
document actually does not introduce “VTN-ID” to IS-IS, IMO reserving a block 
of VTN-ID seems not relevant to this document.
 
An IS-IS MT has the attributes of a VTN, including the specific topology and 
resource. An IS-IS MT can be used as a VTN and MT-ID can be used as a VTN ID. 
Is it possible for an IS-IS MT to be used/shared by two or more VTNs? If so, it 
seems better to have some details about how the multiple VTNs use/share the 
resource in the same one MT. 
 
[Chongfeng] The presumption of using MT-ID to identify VTNs is that different 
VTNs are identified by different MT-IDs, thus sharing of one MT between 
different VTNs is not allowed in this document. For such sharing mechanism you 
may refer to other documents in the WG. 
 
In section 5 "Scalability Considerations", the draft says that while multiple 
VTNs share the same topology attribute, the same topology is identified by 
multiple different MT-IDs. This seems giving a way to let two or more VTNs to 
use/share one MT if IS-IS MT allows multiple MT-IDs to be used for the same one 
MT. It seems better to move the related text from section 5 to some of the 
previous sections.
 
[Chongfeng] The scalability considerations section describes the potential 
limitations of the MT based approach in scalability. Since each VTN is 
identified by a unique MT-ID, independent path computation would be needed for 
each VTN, even if multiple VTNs has the same topology attribute (they are still 
identified by different MT-IDs). For example, MT-x and MT-y are used to 
identify two VTNs, the topology of them may be the same, but the path 
computation still needs to be done for MT-X and MT-Y separately. Sharing the 
computation overhead among multiple VTNs is discussed in other document, which 
requires some protocol extensions and is out of the scope of this document.
 
Hope this helps to clarify your questions. Thanks. 
 
Best Regards,
Huaimo
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt

[Peter Psenak]

Bruno,

please see inline:



On 20/10/2020 11:43, bruno.decra...@orange.com wrote:

Peter,


From: Peter Psenak [mailto:ppse...@cisco.com]

Bruno,

On 19/10/2020 18:52, bruno.decra...@orange.com wrote:

Ron, all,

>From a use case standpoint, I have a use case for having both SR-MPLS and

IP flexalgo in the same network.


>From a protocol standpoint, I think that the functionality could be equally

met by advertising SR-MPLS SID as per RFC 8667 but using a label 3 (implicit
null) to instruct the LER/LSR to not use a label in the forwarding plane. (while
still advertising a label in the control plane because we have to).

does not work,


I could provide more explanations, but reading your email, it seems to me that 
you understood the proposal.
So it seems to me that the opinion that you really meant is: it works but it 
would be an nasty hack.

Regarding "nasty hack" it could be interesting to have a normative definition. 
This could prove useful in some other contexts.
BTW, is "max metric" a hack (vs creating a new tlv if you don't want the link in the IGP 
SPF), is "implicit null label" a hack. And for BGP, encoding the label in the NLRI...


max-metric does not solve the problem, as you would need a prefix metric 
for non 0 algo anyway.



Coming back to technical comments, note that creating yet another TLV to carry 
IP prefix also brings questions that the draft does not answer or even raise.
- What about the sub-TLVs? Are they shared with the existing registry for 
prefix TLV [1] ? Do we want to exclude some? E.g., Prefix Segment Identifier 
(we would have two algo fields, two ways to signal SIDs...)


yes, these are details that needs to be addressed, but should not be a 
problem. Look at locator TLV in SRv6, very similar concept here.



- for IPv6, the content and meaning of  "ISIS MT IPv6 Flexalgo Prefix Reachability TLV" 
is essentially the same than the "SRv6 Locator TLV".
- Only the naming and the ordering of the fields are different.
- Why do we need two TLVs to advertise the same thing (essentially a 
Routing Algo)? Duplication means more spec, more code, more features to 
implement, more error and bugs. (and it did not took long: the draft defines 
the MTID field as 8 bits while RFC 5120 defines it a 12 bits.


well, locator is a construct that is specific to SRv6. Sure you can 
advertise the prefix in a locator TLV without any SRv6 specific Sub-TLVs 
and achieve the same thing - I have already mentioned that in one of my 
responses, but that is again ugly.



- What is the functional different between FlexAlgo for SRv6 and 
FlexAlgo for IPv6? Both use the IPv6 destination address in the packet and the 
IPv6 FIB in the router.


they are functionally the same.

I believe that having a clean encoding is preferable in a long run. One 
can not advertise a prefix as SRv6 locator as well as IP flex-algo 
prefix (that would be an error), so duplication of data is not an 
issues. And having a dedicated TLV for each is better from both 
deployment and implementation perspective.


thanks,
Peter






Thanks,
Bruno


as it does not allow you to associate the prefix with
Flex-algo without advertising the reachability in algo 0. Making the
prefix reachability in default algo conditional based on the presence of
the Prefix SID Sub-TLV with Imnplicit Null would be a nasty hack.

Not to mention that advertising a Prefix SID in pure IP network would be
ugly.

thanks,
Peter




I feel that this would be less change in the protocol (no new tlv), a good fit

for network requiring both MPLS and IP flex algo, and would not require
implementations/network operator to duplicate the "prefix sub-TLV" [1] on
both advertisements (IP based and SR-MPLS based).


That would still requires a protocol extension/STD track RFC as RFC 8667

does not allow for this. That would still require change to implementations as
only the signalling is different while the feature/behavior is the same (i.e. no
magic).


Regards,
--Bruno

[1] aka "Sub-TLVs for TLVs 135, 235, 236, and 237 (Extended IP reachability,

MT IP. Reach, IPv6 IP. Reach, and MT IPv6 IP. Reach TLVs)"




-Original Message-
From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Ron Bonica
Sent: Tuesday, September 29, 2020 3:38 PM
To: lsr@ietf.org
Subject: [Lsr] FW: New Version Notification for draft-bonica-lsr-ip-

flexalgo-

00.txt


Please review and comment

 Ron



Juniper Business Use Only


-Original Message-
From: internet-dra...@ietf.org 
Sent: Tuesday, September 29, 2020 9:36 AM
To: Parag Kaneriya ; Shraddha Hegde
; Ron Bonica ; Rajesh M
; William Britto A J 
Subject: New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt

[External Email. Be cautious of content]


A new version of I-D, draft-bonica-lsr-ip-flexalgo-00.txt
has been successfully submitted by Ron Bonica and posted to the IETF
repository.

Name:   draft-bonica-lsr-ip-flexalgo
Revision:   00
T

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

[Lsr] I-D Action: draft-ietf-lsr-ospf-prefix-originator-07.txt

[internet-drafts]

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

Title   : OSPF Prefix Originator Extensions
Authors : Aijun Wang
  Acee Lindem
  Jie Dong
  Peter Psenak
  Ketan Talaulikar
Filename: draft-ietf-lsr-ospf-prefix-originator-07.txt
Pages   : 9
Date: 2020-10-20

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-07
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospf-prefix-originator-07

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-lsr-ospf-prefix-originator-07


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

Re: [Lsr] New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt

[bruno.decraene]

Peter,

> From: Peter Psenak [mailto:ppse...@cisco.com]
> 
> Bruno,
> 
> On 19/10/2020 18:52, bruno.decra...@orange.com wrote:
> > Ron, all,
> >
> >>From a use case standpoint, I have a use case for having both SR-MPLS and
> IP flexalgo in the same network.
> >
> >>From a protocol standpoint, I think that the functionality could be equally
> met by advertising SR-MPLS SID as per RFC 8667 but using a label 3 (implicit
> null) to instruct the LER/LSR to not use a label in the forwarding plane. 
> (while
> still advertising a label in the control plane because we have to).
> 
> does not work,

I could provide more explanations, but reading your email, it seems to me that 
you understood the proposal.
So it seems to me that the opinion that you really meant is: it works but it 
would be an nasty hack.

Regarding "nasty hack" it could be interesting to have a normative definition. 
This could prove useful in some other contexts. 
BTW, is "max metric" a hack (vs creating a new tlv if you don't want the link 
in the IGP SPF), is "implicit null label" a hack. And for BGP, encoding the 
label in the NLRI...


Coming back to technical comments, note that creating yet another TLV to carry 
IP prefix also brings questions that the draft does not answer or even raise.
- What about the sub-TLVs? Are they shared with the existing registry for 
prefix TLV [1] ? Do we want to exclude some? E.g., Prefix Segment Identifier 
(we would have two algo fields, two ways to signal SIDs...)
- for IPv6, the content and meaning of  "ISIS MT IPv6 Flexalgo Prefix 
Reachability TLV" is essentially the same than the "SRv6 Locator TLV".
- Only the naming and the ordering of the fields are different.
- Why do we need two TLVs to advertise the same thing (essentially a 
Routing Algo)? Duplication means more spec, more code, more features to 
implement, more error and bugs. (and it did not took long: the draft defines 
the MTID field as 8 bits while RFC 5120 defines it a 12 bits.
- What is the functional different between FlexAlgo for SRv6 and 
FlexAlgo for IPv6? Both use the IPv6 destination address in the packet and the 
IPv6 FIB in the router.

Thanks,
Bruno

> as it does not allow you to associate the prefix with
> Flex-algo without advertising the reachability in algo 0. Making the
> prefix reachability in default algo conditional based on the presence of
> the Prefix SID Sub-TLV with Imnplicit Null would be a nasty hack.
> 
> Not to mention that advertising a Prefix SID in pure IP network would be
> ugly.
> 
> thanks,
> Peter
> 
> 
> 
> > I feel that this would be less change in the protocol (no new tlv), a good 
> > fit
> for network requiring both MPLS and IP flex algo, and would not require
> implementations/network operator to duplicate the "prefix sub-TLV" [1] on
> both advertisements (IP based and SR-MPLS based).
> >
> > That would still requires a protocol extension/STD track RFC as RFC 8667
> does not allow for this. That would still require change to implementations as
> only the signalling is different while the feature/behavior is the same (i.e. 
> no
> magic).
> >
> > Regards,
> > --Bruno
> >
> > [1] aka "Sub-TLVs for TLVs 135, 235, 236, and 237 (Extended IP reachability,
> MT IP. Reach, IPv6 IP. Reach, and MT IPv6 IP. Reach TLVs)"
> >
> >
> >> -Original Message-
> >> From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Ron Bonica
> >> Sent: Tuesday, September 29, 2020 3:38 PM
> >> To: lsr@ietf.org
> >> Subject: [Lsr] FW: New Version Notification for draft-bonica-lsr-ip-
> flexalgo-
> >> 00.txt
> >>
> >>
> >> Please review and comment
> >>
> >> Ron
> >>
> >>
> >>
> >> Juniper Business Use Only
> >>
> >>> -Original Message-
> >>> From: internet-dra...@ietf.org 
> >>> Sent: Tuesday, September 29, 2020 9:36 AM
> >>> To: Parag Kaneriya ; Shraddha Hegde
> >>> ; Ron Bonica ; Rajesh M
> >>> ; William Britto A J 
> >>> Subject: New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt
> >>>
> >>> [External Email. Be cautious of content]
> >>>
> >>>
> >>> A new version of I-D, draft-bonica-lsr-ip-flexalgo-00.txt
> >>> has been successfully submitted by Ron Bonica and posted to the IETF
> >>> repository.
> >>>
> >>> Name:   draft-bonica-lsr-ip-flexalgo
> >>> Revision:   00
> >>> Title:  IGP Flexible Algorithms (Flexalgo) In IP Networks
> >>> Document date:  2020-09-29
> >>> Group:  Individual Submission
> >>> Pages:  14
> >>> URL:https://urldefense.com/v3/__https://www.ietf.org/id/draft-
> >> bonica-
> >>> lsr-ip-flexalgo-00.txt__;!!NEt6yMaO-gk!X7PVDP-
> >>> FnUA0oCcZMw3Qde6in0C72hu_9hOZ53kPspIarR8fNDyU9Vck80Zbjoij$
> >>> Status:
> >>> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-
> >> bonica-lsr-
> >>> ip-flexalgo/__;!!NEt6yMaO-gk!X7PVDP-
> >>> FnUA0oCcZMw3Qde6in0C72hu_9hOZ53kPspIarR8fNDyU9Vck8x7e5ZqI$
> >>> Htmlized:
> >>>
> https://urldefense.com/v3/__https://datatracker.ietf.o

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