Re: [Lsr] Comments on Requested Codepoints for draft-li-lsr-isis-area-proxy

2020-06-30 Thread tony . li

Hi all,

The authors are on-board with this round of suggestions from Les.  Could I get 
a review by one more of our Designated Experts before we update the draft?

Thanks,
Tony


> On Jun 29, 2020, at 3:07 PM, Les Ginsberg (ginsberg)  
> wrote:
> 
> Tony –
>  
> Inline.
>  
> From: Tony Li mailto:tony1ath...@gmail.com>> On 
> Behalf Of tony...@tony.li 
> Sent: Monday, June 29, 2020 2:37 PM
> To: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>
> Cc: Hannes Gredler mailto:han...@gredler.at>>; 
> draft-li-lsr-isis-area-proxy.auth...@ietf.org 
> ; lsr@ietf.org 
> 
> Subject: Re: [Lsr] Comments on Requested Codepoints for 
> draft-li-lsr-isis-area-proxy
>  
>  
>  
> Hi Les,
>  
> 
> 
> On Jun 29, 2020, at 2:13 PM, Les Ginsberg (ginsberg)  > wrote:
>  
> Tony –
>  
> OLD:
> 1)Area Proxy Router Capability - sub-TLV of Router Capability TLV
>  
> 2)Inside Node TLV - Top level TLV
>  
> 3)Area Proxy TLV - Top Level TLV with optional sub-TLVs:
>Sub-TLV Area Proxy System ID
>Sub-TLV Area Segment SID
>  
> 4)Area Segment SID - Top Level TLV
>  
> NEW: (Please check my interpretation)
>  
> 1)Area Proxy Router Capability - sub-TLV of Router Capability TLV
>  
> 2)Area Proxy TLV - Top Level TLV with optional sub-TLVs:
>Sub-TLV Area Proxy System ID
>Sub-TLV Area Segment SID
>Sub-TLV Inside Node ???
>  
> 3)Area Segment SID - Top Level TLV
>  
> Am I correct so far??
>  
>  
> Yes, exactly.  Inside node would be a sub-TLV or a flag, TBD.
>  
>  
> If so, a couple more comments/suggestions:
>  
> a)Could the Area Proxy TLV become a bit more generic and allow advertisement 
> of the capability (implied by presence of the TLV)?
> If  so, the Router Capability sub-TLV could go away.
>  
>  
> Speaking just for myself, ok, that seems reasonable and doable.
>  
> 
> 
> b)If the Area Segment SID is (as you suggest) a generic thing not specific to 
> Area Proxy, then I would point you to 
> https://www.rfc-editor.org/rfc/rfc8667.html#section-2.4.1 
> 
>  
>  
> ?  Your pointer is to the flags field of the SID/Label Binding TLV.
>  
> [Les:] Yes – as the suggestion would be to add another flag definition.
> 
> 
> This allows SIDs to be advertised in the SID Binding TLV for a special 
> purpose (see the Mirror SID). One could imagine another flag bit to indicate 
> this is an Area SID.
>  
>  
> You’re suggesting a bit in the flags, the range would be unused, and a prefix 
> length of 0? Then the actual SID would be in the SID/Label sub-TLV?
>  
> [Les:]Range could be specified as ignored in this case. Prefix length would 
> be 0.
> The SID would be – as you say – advertised in the SID/Label sub-TLV – as with 
> all other SIDs.
> 
> 
> I think this would need to be vetted with SR  folks 
>  
>  
> That will happen, regardless of how we proceed.
>  
> 
> 
> – but I would like to avoid advertising a SID in a way different from all 
> other SIDs i.e., SIDs currently are always a sub-TLV of some top level TLV – 
> whether it be Prefix Reachability (Prefix-SID), IS Neighbor (Adjacency SID), 
> or Binding SID (Mirror SID).
>  
>  
> We were trying to extend the current design consistently with existing SIDs.  
> As the Prefix SID and Adjacency SID were top level, it made sense to continue 
> that approach.  The approach of the Binding SID TLV would seem to mix all 
> semantics into one encoding and seems inconsistent and complicated with 
> respect to the other SIDs.  If this was the intent, shouldn’t prefix and 
> adjacency SIDs be encoded in this TLV as well?
> [Les:] Prefix/adjacency SIDs are sub-TLVs of TLVs 135 and 22 respectively.
>  
> There’s only three available bits (plus one octet) here.  Aren’t we concerned 
> about running out of bits if we go this direction?
> [Les:] I am not. It is a question of whether SR sees this as a useful type of 
> SID. If so, it merits a bit.
>  
>Les
>  
> Tony

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


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

2020-06-30 Thread 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-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


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

2020-06-30 Thread 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

2020-06-30 Thread 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


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

2020-06-30 Thread 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 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] IANA early allocation request for draft-ietf-lsr-ospf-bfd-strict-mode

2020-06-30 Thread 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] draft-ietf-lsr-flex-algo

2020-06-30 Thread Peter Psenak

Hi Bruno,

please see inline:

On 30/06/2020 16:53, bruno.decra...@orange.com wrote:

Hi all,

I can live with the current text, but I'm just raising the point for discussion 
(better safe than sorry).

"16.1.1.  IGP Algorithm Types Registry

This document makes the following registrations in the "IGP Algorithm 
Types" registry:

   Type: 128-255.

   Description: Flexible Algorithms.
"
https://tools.ietf.org/html/draft-ietf-lsr-flex-algo-07#section-16.1.1

This is essentially burning half of the registry for flex-algo. Indeed, any 
network operator could use any value, e.g. 222, hence the IETF could never 
define a different usage for this value without creating interop issues for the 
network operator.


what is the real problem? Is the space 2-127 that is free not sufficient 
for other standardized algorithms that may come?




We could discuss whether we really need 127 values for this. (i.e. a network 
operator requiring 127 flex algo, typically multiplying its IGP FIB entries by 
127...).


above is not necessarily true and more importantly completely irrelevant 
to the number of algos we reserve for FA.




We could also discuss whether this range could be change to the IANA well-known 
"Private Use" [1]. This would allow for alternative private usages in the 
future (e.g. Flexible Alorithms v2).
[1] https://tools.ietf.org/html/rfc8126#section-4.1

It seems to me that the latter would equally work for flex algo, but would 
provide more flexibility :-) for the future.


I don't think so. We need an allocated range of algos for FA for 
compatibility.



thanks,
Peter


Regards,
--Bruno

_

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




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


[Lsr] WG adoption request for draft-ketant-lsr-ospf-l2bundles

2020-06-30 Thread 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] I-D Action: draft-ietf-ospf-te-link-attr-reuse-16.txt

2020-06-30 Thread 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 Application-Specific Link Attributes
Authors : Peter Psenak
  Les Ginsberg
  Wim Henderickx
  Jeff Tantsura
  John Drake
Filename: draft-ietf-ospf-te-link-attr-reuse-16.txt
Pages   : 22
Date: 2020-06-30

Abstract:
   Existing traffic engineering related link attribute advertisements
   have been defined and are used in RSVP-TE deployments.  Since the
   original RSVP-TE use case was defined, additional applications (e.g.,
   Segment Routing Policy, Loop Free Alternate) have been defined that
   also make use of the link attribute advertisements.  In cases where
   multiple applications wish to make use of these link attributes the
   current advertisements do not support application specific values for
   a given attribute nor do they support indication of which
   applications are using the advertised value for a given link.  This
   document introduces new link attribute advertisements in OSPFv2 and
   OSPFv3 that address both of these shortcomings.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-ospf-te-link-attr-reuse/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-ospf-te-link-attr-reuse-16
https://datatracker.ietf.org/doc/html/draft-ietf-ospf-te-link-attr-reuse-16

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-ospf-te-link-attr-reuse-16


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] draft-ietf-lsr-flex-algo

2020-06-30 Thread bruno.decraene
Hi all,

I can live with the current text, but I'm just raising the point for discussion 
(better safe than sorry).

"16.1.1.  IGP Algorithm Types Registry

   This document makes the following registrations in the "IGP Algorithm Types" 
registry:

  Type: 128-255.

  Description: Flexible Algorithms.
"
https://tools.ietf.org/html/draft-ietf-lsr-flex-algo-07#section-16.1.1

This is essentially burning half of the registry for flex-algo. Indeed, any 
network operator could use any value, e.g. 222, hence the IETF could never 
define a different usage for this value without creating interop issues for the 
network operator.

We could discuss whether we really need 127 values for this. (i.e. a network 
operator requiring 127 flex algo, typically multiplying its IGP FIB entries by 
127...).
We could also discuss whether this range could be change to the IANA well-known 
"Private Use" [1]. This would allow for alternative private usages in the 
future (e.g. Flexible Alorithms v2).
[1] https://tools.ietf.org/html/rfc8126#section-4.1

It seems to me that the latter would equally work for flex algo, but would 
provide more flexibility :-) for the future.

Regards,
--Bruno

_

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] draft-ietf-lsr-flex-algo

2020-06-30 Thread bruno.decraene
Hi Peter,

Thanks for your reply.

> From: Peter Psenak [mailto:ppse...@cisco.com]
> 
> Hi Bruno,
> 
> please see inline:
> 
> On 30/06/2020 16:53, bruno.decra...@orange.com wrote:
> > Hi all,
> >
> > I can live with the current text, but I'm just raising the point for 
> > discussion
> (better safe than sorry).
> >
> > "16.1.1.  IGP Algorithm Types Registry
> >
> > This document makes the following registrations in the "IGP Algorithm
> Types" registry:
> >
> >Type: 128-255.
> >
> >Description: Flexible Algorithms.
> > "
> > https://tools.ietf.org/html/draft-ietf-lsr-flex-algo-07#section-16.1.1
> >
> > This is essentially burning half of the registry for flex-algo. Indeed, any
> network operator could use any value, e.g. 222, hence the IETF could never
> define a different usage for this value without creating interop issues for 
> the
> network operator.
> 
> what is the real problem? Is the space 2-127 that is free not sufficient
> for other standardized algorithms that may come?
> 
> >
> > We could discuss whether we really need 127 values for this. (i.e. a
> network operator requiring 127 flex algo, typically multiplying its IGP FIB
> entries by 127...).
> 
> above is not necessarily true and more importantly completely irrelevant
> to the number of algos we reserve for FA.
> 
> 
> > We could also discuss whether this range could be change to the IANA well-
> known "Private Use" [1]. This would allow for alternative private usages in
> the future (e.g. Flexible Alorithms v2).
> > [1] https://tools.ietf.org/html/rfc8126#section-4.1
> >
> > It seems to me that the latter would equally work for flex algo, but would
> provide more flexibility :-) for the future.
> 
> I don't think so. We need an allocated range of algos for FA for
> compatibility.

The allocated range of algos for FA would be the same. Just not dedicated to FA.

--Bruno
 
> 
> thanks,
> Peter
> >
> > Regards,
> > --Bruno
> >
> >
> __
> __
> _
> >
> > 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
> >
> >


_

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] draft-ietf-lsr-flex-algo

2020-06-30 Thread Peter Psenak

Hi Bruno,

On 30/06/2020 18:08, bruno.decra...@orange.com wrote:

Hi Peter,

Thanks for your reply.


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

Hi Bruno,

please see inline:

On 30/06/2020 16:53, bruno.decra...@orange.com wrote:

Hi all,

I can live with the current text, but I'm just raising the point for discussion

(better safe than sorry).


"16.1.1.  IGP Algorithm Types Registry

 This document makes the following registrations in the "IGP Algorithm

Types" registry:


Type: 128-255.

Description: Flexible Algorithms.
"
https://tools.ietf.org/html/draft-ietf-lsr-flex-algo-07#section-16.1.1

This is essentially burning half of the registry for flex-algo. Indeed, any

network operator could use any value, e.g. 222, hence the IETF could never
define a different usage for this value without creating interop issues for the
network operator.

what is the real problem? Is the space 2-127 that is free not sufficient
for other standardized algorithms that may come?



We could discuss whether we really need 127 values for this. (i.e. a

network operator requiring 127 flex algo, typically multiplying its IGP FIB
entries by 127...).

above is not necessarily true and more importantly completely irrelevant
to the number of algos we reserve for FA.



We could also discuss whether this range could be change to the IANA well-

known "Private Use" [1]. This would allow for alternative private usages in
the future (e.g. Flexible Alorithms v2).

[1] https://tools.ietf.org/html/rfc8126#section-4.1

It seems to me that the latter would equally work for flex algo, but would

provide more flexibility :-) for the future.

I don't think so. We need an allocated range of algos for FA for
compatibility.


The allocated range of algos for FA would be the same. Just not dedicated to FA.


this would not work. If I have a mix of routers, one set using value 222 
for flex-algo and another set for something else, how are they going to 
interoperate?


We need a standardized range, using Private Use is not an option here.

thanks,
Peter



--Bruno
  


thanks,
Peter


Regards,
--Bruno



__
__
_


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





_

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] draft-ietf-lsr-flex-algo

2020-06-30 Thread Acee Lindem (acee)
Speaking as WG chair:

I'm delighted to see discussion on a draft that isn't in WG last call.

Speaking as WG member:

Maybe I'm missing something but do we really think we’re going to run out of 
non-flexible algorithms with 128? I just don't see it happening in my lifetime. 

Thanks,
Acee



On 6/30/20, 12:27 PM, "Lsr on behalf of Peter Psenak"  wrote:

Hi Bruno,

On 30/06/2020 18:08, bruno.decra...@orange.com wrote:
> Hi Peter,
> 
> Thanks for your reply.
> 
>> From: Peter Psenak [mailto:ppse...@cisco.com]
>>
>> Hi Bruno,
>>
>> please see inline:
>>
>> On 30/06/2020 16:53, bruno.decra...@orange.com wrote:
>>> Hi all,
>>>
>>> I can live with the current text, but I'm just raising the point for 
discussion
>> (better safe than sorry).
>>>
>>> "16.1.1.  IGP Algorithm Types Registry
>>>
>>>  This document makes the following registrations in the "IGP 
Algorithm
>> Types" registry:
>>>
>>> Type: 128-255.
>>>
>>> Description: Flexible Algorithms.
>>> "
>>> https://tools.ietf.org/html/draft-ietf-lsr-flex-algo-07#section-16.1.1
>>>
>>> This is essentially burning half of the registry for flex-algo. Indeed, 
any
>> network operator could use any value, e.g. 222, hence the IETF could 
never
>> define a different usage for this value without creating interop issues 
for the
>> network operator.
>>
>> what is the real problem? Is the space 2-127 that is free not sufficient
>> for other standardized algorithms that may come?
>>
>>>
>>> We could discuss whether we really need 127 values for this. (i.e. a
>> network operator requiring 127 flex algo, typically multiplying its IGP 
FIB
>> entries by 127...).
>>
>> above is not necessarily true and more importantly completely irrelevant
>> to the number of algos we reserve for FA.
>>
>>
>>> We could also discuss whether this range could be change to the IANA 
well-
>> known "Private Use" [1]. This would allow for alternative private usages 
in
>> the future (e.g. Flexible Alorithms v2).
>>> [1] https://tools.ietf.org/html/rfc8126#section-4.1
>>>
>>> It seems to me that the latter would equally work for flex algo, but 
would
>> provide more flexibility :-) for the future.
>>
>> I don't think so. We need an allocated range of algos for FA for
>> compatibility.
> 
> The allocated range of algos for FA would be the same. Just not dedicated 
to FA.

this would not work. If I have a mix of routers, one set using value 222 
for flex-algo and another set for something else, how are they going to 
interoperate?

We need a standardized range, using Private Use is not an option here.

thanks,
Peter

> 
> --Bruno
>   
>>
>> thanks,
>> Peter
>>>
>>> Regards,
>>> --Bruno
>>>
>>>
>> __
>> __
>> _
>>>
>>> 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
>>>
>>>
> 
> 
> 
_
> 
> 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 

Re: [Lsr] draft-ietf-lsr-flex-algo

2020-06-30 Thread bruno.decraene
Hi Peter,

> From: Peter Psenak [mailto:ppse...@cisco.com]
> 
> Hi Bruno,
> 
> On 30/06/2020 18:08, bruno.decra...@orange.com wrote:
> > Hi Peter,
> >
> > Thanks for your reply.
> >
> >> From: Peter Psenak [mailto:ppse...@cisco.com]
> >>
> >> Hi Bruno,
> >>
> >> please see inline:
> >>
> >> On 30/06/2020 16:53, bruno.decra...@orange.com wrote:
> >>> Hi all,
> >>>
> >>> I can live with the current text, but I'm just raising the point for
> discussion
> >> (better safe than sorry).
> >>>
> >>> "16.1.1.  IGP Algorithm Types Registry
> >>>
> >>>  This document makes the following registrations in the "IGP Algorithm
> >> Types" registry:
> >>>
> >>> Type: 128-255.
> >>>
> >>> Description: Flexible Algorithms.
> >>> "
> >>> https://tools.ietf.org/html/draft-ietf-lsr-flex-algo-07#section-16.1.1
> >>>
> >>> This is essentially burning half of the registry for flex-algo. Indeed, 
> >>> any
> >> network operator could use any value, e.g. 222, hence the IETF could
> never
> >> define a different usage for this value without creating interop issues for
> the
> >> network operator.
> >>
> >> what is the real problem? Is the space 2-127 that is free not sufficient
> >> for other standardized algorithms that may come?
> >>
> >>>
> >>> We could discuss whether we really need 127 values for this. (i.e. a
> >> network operator requiring 127 flex algo, typically multiplying its IGP FIB
> >> entries by 127...).
> >>
> >> above is not necessarily true and more importantly completely irrelevant
> >> to the number of algos we reserve for FA.
> >>
> >>
> >>> We could also discuss whether this range could be change to the IANA
> well-
> >> known "Private Use" [1]. This would allow for alternative private usages in
> >> the future (e.g. Flexible Alorithms v2).
> >>> [1] https://tools.ietf.org/html/rfc8126#section-4.1
> >>>
> >>> It seems to me that the latter would equally work for flex algo, but
> would
> >> provide more flexibility :-) for the future.
> >>
> >> I don't think so. We need an allocated range of algos for FA for
> >> compatibility.
> >
> > The allocated range of algos for FA would be the same. Just not dedicated
> to FA.
> 
> this would not work. If I have a mix of routers, one set using value 222
> for flex-algo and another set for something else, how are they going to
> interoperate?

My understanding is that the value of the flexalgo is chosen by the network 
operator and configured on the router. 

" We want the mapping between the Flex-Algorithm and it's meaning to be 
flexible and defined by the user."
[...]
" Flexible-Algorithm is a numeric identifier in the range 128-255 that
   is associated via provisioning with the Flexible-Algorithm
   Definition."


IOW, "private or local use only, with the type and
   purpose defined by the local site.  No attempt is made to prevent
   multiple sites from using the same value in different (and
   incompatible) ways.  IANA does not record assignments from registries
   or ranges with this policy (and therefore there is no need for IANA
   to review them) and assignments are not generally useful for broad
   interoperability.  It is the responsibility of the sites making use
   of the Private Use range to ensure that no conflicts occur (within
   the intended scope of use)."

Which is the definition of Private Use by IANA.


> We need a standardized range, using Private Use is not an option here.

Yes we need a standardized range.
I'm not sure that this range needs to be dedicated to FA. But I leave this to 
you/the WG.

And thanks again for your active engagement in the discussion.

-- Bruno

> thanks,
> Peter
> 
> >
> > --Bruno
> >
> >>
> >> thanks,
> >> Peter
> >>>
> >>> Regards,
> >>> --Bruno
> >>>
> >>>
> >>
> __
> >>
> __
> >> _
> >>>
> >>> 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
> >>>