Re: [Lsr] [netmod] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt

[Joel M. Halpern]

That does summary below does not match what others have said on this thread.

Yours,
Joel

On 4/14/2022 12:23 PM, Andy Bierman wrote:



On Thu, Apr 14, 2022 at 8:01 AM Acee Lindem (acee) 
mailto:40cisco@dmarc.ietf.org>> wrote:


While RFC 4001 really didn't need to extend the zone index to IPv4,
the conversation also pertains to IPv6 address types. At least RFC
4001 got it right by not making the zone index part of the default
types and defining ipv4z and ipv6z.


So is this a correct summary:

  - zone index is not used in IPv4 at all
  - zone index is not configured by a client in IPv6 at all
  - zone index is assigned by the system (as needed) to IPv6 link-local 
addresses


I want to add a server option in our code to always reject (or alter)
an edit that contains a zone index.  I need to know the consensus on
whether it is OK to ignore a zone index from a client.
Nothing in RFC 6241 suggests that this is OK for .


Thanks,
Acee


Andy

On 4/14/22, 10:04 AM, "Lsr on behalf of Martin Björklund"
mailto:lsr-boun...@ietf.org> on behalf of
mbj+i...@4668.se > wrote:

     I thought the discussion was only about ipv4?


     /martin


     Jürgen Schönwälder mailto:j.schoenwael...@jacobs-university.de>> wrote:
     > On Thu, Apr 14, 2022 at 03:23:31PM +0200, Martin Björklund wrote:
     > > Hi,
     > >
     > > First of all, I agree that if we were to design this from
scratch, I
     > > think we should have a type for just an ip address, and use
a second
     > > leaf for the zone (or interface).
     > >
     >
     > The notation 'fe80::4d9:ff04:4fa6:7980%en0' is widely
supported in
     > application space. The IPv6 working group has a recurring
debate on
     > the usage of zoned IPv6 address in URLs [1], where the debate
is about
     > the question whether the % needs to be escaped or not. I do
not know
     > where the latest iteration stopped, but details can be found
in RFC
     > 6874 and draft-carpenter-6man-rfc6874bis-03.
     >
     > Philip Homburg's RIPE Labs note [2] might also be an interesting
     > read. According to this, getaddrinfo() actually deals with zoned
     > addresses (and hence even data model implementation that pass
data to
     > getaddrinfo() to obtain socket addresses may do the right thing.)
     >
     > My view is that down in the network layer models, you often
know the
     > interface by context and ipv6-address-no-zone is sufficient.
If you go
     > to application space, you really want "ipv6-address-with-zone" by
     > default in order to support link-local addresses.
     >
     > /js
     >
     > [1] http://[fe80::4d9:ff04:4fa6:7980%en0]/
     >
     > [2]

https://labs.ripe.net/author/philip_homburg/whats-the-deal-with-ipv6-link-local-addresses/


     >
     > --
     > Jürgen Schönwälder              Jacobs University Bremen gGmbH
     > Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen
| Germany
     > Fax:   +49 421 200 3103   
  >

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


___
netmod mailing list
net...@ietf.org 
https://www.ietf.org/mailman/listinfo/netmod



___
netmod mailing list
net...@ietf.org
https://www.ietf.org/mailman/listinfo/netmod


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

Re: [Lsr] [netmod] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt

[Joel M. Halpern]

Juergen posted an example of where ip-address is used and zones are 
expected.


Yours,
Joel

On 4/12/2022 9:24 AM, Acee Lindem (acee) wrote:

Joel,

There are plenty of examples of where the ip-address types are used and a zone 
is not accepted. Show me the examples where it is expected? I do have reason to 
believe there aren't any significant usages of the ip-address types where zone 
is accepted. Show me the models

Acee

On 4/11/22, 1:44 PM, "Lsr on behalf of Joel M. Halpern"  wrote:

 Do we have reason to believe that no one outside the IETF has used
 ip-address as we published in ways that need a zone?

 It seems to me that the first step in the plan below is reasonable.  But
 changing ip-address itself seems a bad idea.  If one means no-zone, use
 the -no-zone typedef.

 Yours,
 Joel

 On 4/11/2022 1:28 PM, Andy Bierman wrote:
 >
 >
 > On Mon, Apr 11, 2022 at 10:07 AM Rob Wilton (rwilton)
 > mailto:40cisco@dmarc.ietf.org>>
 > wrote:
 >
 > Hi all,
 >
 > Thanks for the comments on this thread so far.  It would be nice if
 > we are able to come to some sort of rough consensus to a solution.
 >
 > I think that there is consensus that the YANG type ip-address (and
 > the v4/v6 versions) are badly named as the prominent default type
 > name has been given to the unusual variant of including zone
 > information.
 >
 > Based on the comments on this thread, it also seems likely to me
 > that most of the usages of ip-address in YANG RFCs is likely to be
 > wrong, and the intention was that IP addresses without zones was
 > intended.  At a rough count, of the published RFC YANG models at
 > github YangModels/standard/ietf/RFC/ to be:
 >  86 uses of ip-address
 >  68 uses of ipv4-address
 >  66 uses of ipv6-address
 >
 >  1 use of ip-address-no-zone
 >  4 uses of ipv4-address-no-zone
 >  4 uses of ipv6-address-no-zone
 >
 > These types appear in 49 out of the 141 YANG modules published in
 > RFCs.  At a quick guess/check it looks like these 49 YANG modules
 > may appear in 40-50 RFCs.
 >
 > As mentioned previously, it is also worth comparing this to the
 > OpenConfig YANG modules:
 > They have redefined ip-address (and v4/v6 variants) to exclude zone
 > information and have defined separate types include zone information.
 > There are no explicit uses of the "-zoned" variants of OpenConfig IP
 > addresses in the latest OpenConfig github repository.  However,
 > approximately a third of the IP address types are still to the
 > ietf-inet-types.yang rather than openconfig-inet-types.yang, so in
 > theory some of those 58 entries could still intentionally be
 > supporting zoned IP addresses, but I would expect that the vast
 > majority would not.
 > I do see some strong benefit if this basic type being defined in the
 > same way in both IETF and OC YANG, and I believe that the OC folks
 > have got the definition right.
 >
 > I see that some are arguing that the zone in the ip-address
 > definition is effectively optional, and implementations are not
 > really obliged to implement it.  I don't find that argument
 > compelling, at least not with the current definition of ip-address
 > in RFC 6991.  I see a clear difference between a type defined with
 > an incomplete regex that may allow some invalid values and a type
 > that is explicitly defined to included additional values in the
 > allowable value space.  Further, I believe that a client just
 > looking at the YANG module could reasonably expect a server that
 > implements a data node using ip-address would be expected to support
 > IP zones, where they are meaningful, or otherwise they should
 > deviate that data node to indicate that they don't conform to the 
model.
 >
 > We also need to be realistic as to what implementations will do.
 > They are not going to start writing code to support zones just
 > because they are in the model.  They will mostly reject IP addresses
 > with zone information.  Perhaps some will deviate the type to
 > ip-address-no-zone, but probably most won't.
 >
 > The option of respinning approx. 40-50 RFCs to fix this doesn't feel
 > at all appealing.  This would take a significant amount of
 > time/effort and I think th

Re: [Lsr] [netmod] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt

[Joel M. Halpern]

Do we have reason to believe that no one outside the IETF has used 
ip-address as we published in ways that need a zone?


It seems to me that the first step in the plan below is reasonable.  But 
changing ip-address itself seems a bad idea.  If one means no-zone, use 
the -no-zone typedef.


Yours,
Joel

On 4/11/2022 1:28 PM, Andy Bierman wrote:



On Mon, Apr 11, 2022 at 10:07 AM Rob Wilton (rwilton) 
mailto:40cisco@dmarc.ietf.org>> 
wrote:


Hi all,

Thanks for the comments on this thread so far.  It would be nice if
we are able to come to some sort of rough consensus to a solution.

I think that there is consensus that the YANG type ip-address (and
the v4/v6 versions) are badly named as the prominent default type
name has been given to the unusual variant of including zone
information.

Based on the comments on this thread, it also seems likely to me
that most of the usages of ip-address in YANG RFCs is likely to be
wrong, and the intention was that IP addresses without zones was
intended.  At a rough count, of the published RFC YANG models at
github YangModels/standard/ietf/RFC/ to be:
         86 uses of ip-address
         68 uses of ipv4-address
         66 uses of ipv6-address

         1 use of ip-address-no-zone
         4 uses of ipv4-address-no-zone
         4 uses of ipv6-address-no-zone

These types appear in 49 out of the 141 YANG modules published in
RFCs.  At a quick guess/check it looks like these 49 YANG modules
may appear in 40-50 RFCs.

As mentioned previously, it is also worth comparing this to the
OpenConfig YANG modules:
They have redefined ip-address (and v4/v6 variants) to exclude zone
information and have defined separate types include zone information.
There are no explicit uses of the "-zoned" variants of OpenConfig IP
addresses in the latest OpenConfig github repository.  However,
approximately a third of the IP address types are still to the
ietf-inet-types.yang rather than openconfig-inet-types.yang, so in
theory some of those 58 entries could still intentionally be
supporting zoned IP addresses, but I would expect that the vast
majority would not.
I do see some strong benefit if this basic type being defined in the
same way in both IETF and OC YANG, and I believe that the OC folks
have got the definition right.

I see that some are arguing that the zone in the ip-address
definition is effectively optional, and implementations are not
really obliged to implement it.  I don't find that argument
compelling, at least not with the current definition of ip-address
in RFC 6991.  I see a clear difference between a type defined with
an incomplete regex that may allow some invalid values and a type
that is explicitly defined to included additional values in the
allowable value space.  Further, I believe that a client just
looking at the YANG module could reasonably expect a server that
implements a data node using ip-address would be expected to support
IP zones, where they are meaningful, or otherwise they should
deviate that data node to indicate that they don't conform to the model.

We also need to be realistic as to what implementations will do. 
They are not going to start writing code to support zones just

because they are in the model.  They will mostly reject IP addresses
with zone information.  Perhaps some will deviate the type to
ip-address-no-zone, but probably most won't.

The option of respinning approx. 40-50 RFCs to fix this doesn't feel
at all appealing.  This would take a significant amount of
time/effort and I think that we will struggle to find folks who are
willing to do this.  Although errata could be used to point out the
bug, then can't be used to fix it, all the errata would be "hold for
document update" at best.  Further, during the time that it would
take us to fix it, it is plausible that more incorrect usages of
ip-address will likely occur (but perhaps could be policed via
scripted checks/warnings).


I still feel the right long-term solution here is to get to a state
where the "ip-address" type means what 99% of people expect it to
mean, i.e., excluding zone information.

Given the pushback on making a single non-backwards compatible
change to the new definition, I want to ask whether the following
might be a possible path that gains wider consensus:

(1) In RFC 6991 bis, I propose that we:
(i) define new ip-address-with-zone types (and v4 and v6 versions)
and keep the -no-zone versions.
(ii) we change the description of "ip-address" to indicate:
- Although the type allows for zone information, many
implementations are unlikely to accept zone information in most
scenarios (i.e., so the description of the type more accurately
reflects reality).
- A 

Re: [Lsr] [netmod] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt

[Joel M. Halpern]

Given that you are asking for an incompatible change to an existing 
module, the shoe would seem to be on the other foot.


If you could show it was necessary to make such an incompatible change, 
then there would be a difficult argument to be had.  But you simply have 
not shown it.  (And showing that no one uses the zone field would seem 
the reasonable and impossible bar for doing such.)


Yours,
Joel

On 4/7/2022 1:22 PM, Acee Lindem (acee) wrote:

Hi Joel,

On 4/7/22, 1:18 PM, "Joel M. Halpern"  wrote:

 Acee, I am missing something basic.
 It seems to me that it would be very wrong for the LSR YANG module to
 demand a change to an important type because it turns out that type
 doesn't mean what LSR thought it meant.  Such an error is LSR's problem,
 not the underlying modules.

 There seem to be two fixes.  If it is for some reason imperitive to us
 the same typedef we have been using, then put in text / patterns /
 restrictions saying that this model MUST NOT use the scope field.

 More reasonably, use a different typedef in this model.

Point me to a usages where the zone is actually desired and supported?

Acee




 Yours,
 Joel

 On 4/7/2022 1:04 PM, Acee Lindem (acee) wrote:
 > Hi Martin,
 >
 > On 4/7/22, 1:02 PM, "netmod on behalf of Martin Björklund" 
 wrote:
 >
 >  Andy Bierman  wrote:
 >  > On Thu, Apr 7, 2022 at 9:11 AM tom petch  
wrote:
 >  >
 >  > > From: Lsr  on behalf of Rob Wilton 
(rwilton)
 >  > > 
 >  > > Sent: 07 April 2022 10:25
 >  > >
 >  > > I basically agree with Acee, and I think that we should do (b):
 >  > >
 >  > > b) Change the types as suggested and accept that doing 
so breaks
 >  > > modules where zone indexes are meaningful.
 >  > >
 >  > > 
 >  > >
 >  > > I am concerned that such behaviour will damage the standing of 
the IETF at
 >  > > large.
 >  > >
 >  > >
 >  > MAY for the client means MUST for the server.
 >
 >  I'm not sure what you mean here.
 >
 >  But I'm also not sure I understand what the real problem is.  Just 
b/c
 >  the type allows a zone doesn't mean that all leafs that use this 
type
 >  MUST support a zone.  Compare with the value "0.0.0.0".  It is a 
legal
 >  value according to the pattern, but it will not be valid in all 
places
 >  where this type is used.  And even when an implementation supports
 >  zones, it will not accept all legal (according to the pattern) 
values
 >  for the zone index.  Perhaps the solution is to explain this
 >  better in the description?
 >
 >
 >  > But if no servers actually support it, because the YANG does not 
match
 >  > the operational requirements, then is it really a MUST 
requirement?
 >  >
 >  > This seems like a bugfix, and the worst thing the IETF could do 
wrt/
 >  > standing
 >  > is to force the world to change every module that imports the 
typedef.
 >  > Since many people were not aware of the full syntax, it is not 
clear that
 >  > the WG intent was to include a zone.
 >
 >  It is pretty clear IMO that this was not a mistake.  The text
 >  explicitly says:
 >
 >The IPv4 address may include a zone
 >index, separated by a % sign.
 >
 >  >
 >  > Seems like a bugfix to a pattern, like we have done several times 
already.
 >
 >  I don't think this is a bugfix.
 >
 > A bugfix for the requirements for the base types that requires fixing 
the pattern and description.
 >
 > Acee
 >
 >
 >  /martin
 >
 >
 >  >
 >  > Andy
 >  >
 >  >
 >  >
 >  > > We clearly laid down rules as to what updates were regarded as 
compatible
 >  > > so that authors of software could be confident that their work 
was robust
 >  > > and future-proof.  We did it with SNMP, inter alia, and we have 
carried
 >  > > that forward with YANG.  To tear up that understanding , 
creating who knows
 >  > > how much disruption, can only harm the standing of IETF.
 >  > >
 >  > > Much has been said about how implementations have assumed that 
the address
 >  > > types do not include

Re: [Lsr] [netmod] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt

[Joel M. Halpern]

Acee, I am missing something basic.
It seems to me that it would be very wrong for the LSR YANG module to 
demand a change to an important type because it turns out that type 
doesn't mean what LSR thought it meant.  Such an error is LSR's problem, 
not the underlying modules.


There seem to be two fixes.  If it is for some reason imperitive to us 
the same typedef we have been using, then put in text / patterns / 
restrictions saying that this model MUST NOT use the scope field.


More reasonably, use a different typedef in this model.

Yours,
Joel

On 4/7/2022 1:04 PM, Acee Lindem (acee) wrote:

Hi Martin,

On 4/7/22, 1:02 PM, "netmod on behalf of Martin Björklund" 
 wrote:

 Andy Bierman  wrote:
 > On Thu, Apr 7, 2022 at 9:11 AM tom petch  wrote:
 >
 > > From: Lsr  on behalf of Rob Wilton (rwilton)
 > > 
 > > Sent: 07 April 2022 10:25
 > >
 > > I basically agree with Acee, and I think that we should do (b):
 > >
 > > b) Change the types as suggested and accept that doing so 
breaks
 > > modules where zone indexes are meaningful.
 > >
 > > 
 > >
 > > I am concerned that such behaviour will damage the standing of the 
IETF at
 > > large.
 > >
 > >
 > MAY for the client means MUST for the server.

 I'm not sure what you mean here.

 But I'm also not sure I understand what the real problem is.  Just b/c
 the type allows a zone doesn't mean that all leafs that use this type
 MUST support a zone.  Compare with the value "0.0.0.0".  It is a legal
 value according to the pattern, but it will not be valid in all places
 where this type is used.  And even when an implementation supports
 zones, it will not accept all legal (according to the pattern) values
 for the zone index.  Perhaps the solution is to explain this
 better in the description?


 > But if no servers actually support it, because the YANG does not match
 > the operational requirements, then is it really a MUST requirement?
 >
 > This seems like a bugfix, and the worst thing the IETF could do wrt/
 > standing
 > is to force the world to change every module that imports the typedef.
 > Since many people were not aware of the full syntax, it is not clear that
 > the WG intent was to include a zone.

 It is pretty clear IMO that this was not a mistake.  The text
 explicitly says:

   The IPv4 address may include a zone
   index, separated by a % sign.

 >
 > Seems like a bugfix to a pattern, like we have done several times 
already.

 I don't think this is a bugfix.

A bugfix for the requirements for the base types that requires fixing the 
pattern and description.

Acee


 /martin


 >
 > Andy
 >
 >
 >
 > > We clearly laid down rules as to what updates were regarded as 
compatible
 > > so that authors of software could be confident that their work was 
robust
 > > and future-proof.  We did it with SNMP, inter alia, and we have carried
 > > that forward with YANG.  To tear up that understanding , creating who 
knows
 > > how much disruption, can only harm the standing of IETF.
 > >
 > > Much has been said about how implementations have assumed that the 
address
 > > types do not include a zone but no evidence has been put forward for 
that
 > > assertion.
 > >
 > > I have always assumed that software uses libraries and that the 
libraries
 > > have been written with an understanding of the specifications such 
that if
 > > a zone is received over the wire in conformance with the specification 
but
 > > where the display, field or such like does not allow for a zone, then,
 > > tolerant of what to accept, the zone is silently discarded and the 
address
 > > is used without the zone.  But, like the assertion that keeping the 
zone
 > > will cause who knows what damage, I have not done the research to
 > > substantiate that assumption.
 > >
 > > Tom Petch
 > >
 > > I appreciate that this is an NBC change, but I believe that this is the
 > > most intuitive definition and is the best choice longer term.  I also 
note
 > > that the base ipv4-address/ipv6-address types in OpenConfig (where 
they use
 > > the OC copy/version of inet-types and not ietf-inet-types) don't allow 
a
 > > zone to be specified and assumes the default zone.  They have separate
 > > types in cases where a zone is allowed to be specified, i.e., aligned 
to
 > > what (b) proposes.
 > >
 > > For modules that are using/wanting zones (if any), then they can 
migrate
 > > to the new explicit zone type.   
draft-ietf-netmod-yang-module-versioning,
 > > if it keeps its import "revision-or-derived" extension, would also 
allow
 > > such modules to indicate the dependency on the updated 
revision/definition
 > > of 

Re: [Lsr] IP layer metrics collected by Edge routers - draft-dunbar-lsr-5g-edge-compute-ospf-ext (was: LSR Presentation Slot request)

[Joel M. Halpern]

If you want to experiment with unusual metrics, and minimize the degree 
to which you need consistency, maybe you should look at running a 
different routing protocol in this limited domain?  Rather than trying 
to make IS-IS and OSPF do something they are not designed for?  (While 
there are probably other alternatives, Babel comes to mind as a routing 
protocol designed with experimentaiton with metrics in mind.)


Yours,
Joel

On 7/14/2021 12:20 PM, Linda Dunbar wrote:

Acee,

The “limited domain” per RFC8799  is a special purposed network that 
have boundary, e.g. DetNet. For 5G EC, a Limited Domain network could be 
built specifically for Unmanned Aerial Vehicles (UAV), as specified by 
3GPP 23.748.  This UAV Limited Domain network has routers and links that 
connect the moving UAVs with the UAV control servers, the analytics 
functions, and data storages; has boundary and  may not have access to 
public internet.


Among those routers in the UAV Limited Domain, the routing distance 
alone is no longer enough in computing the optimal Path. Therefore, IGP 
is needed to distribute not only link bandwidth, but also the IP layer 
Metrics specified by draft-dunbar-lsr-5g-edge-compute-ext, specifically:


  * Capacity Index:

Is used to differentiate the running environment of the attached 
application server (analytics or data storages) that are identified by 
their IP addresses.  At some sites, the IP address exposed to the 
network is the App Layer Load balancer that have  many instances 
attached.  At other sites,  the IP address exposed is the server 
instance only.


“Capacity Index”, which is a numeric number configured by the Domain 
Controller on all A-ERs in the domain consistently , is used to 
represent the capacity of the application server attached to an A-ER.


  * Site preference index: 

Is used to describe some sites are more preferred than others for some 
flows that are identified by the IP header fields. “Site Preference 
Index”, which is a numeric number configured by the Domain Controller.


  * IP-Layer Metric for gauging the Load for the attached Prefix (i.e.,
App Server):

The Load Measurement to an attached IP prefix (App Server) is a weighted 
combination of the number of packets/bytes to the IP prefix and the 
number of packets/bytes from the IP prefix which are collected by the 
A-ER that has the App Server directly attached.


An A-ER only collects those measurement for the prefixes instructed by 
the Domain Controller .


The work proposed is for the LSR Chartered Work Item “4) Extensions for 
source-destination routing”.


Is this description clear enough to move forward in the LSR WG?

Best regards, Linda Dunbar

*From:* Acee Lindem (acee) 
*Sent:* Tuesday, July 13, 2021 2:46 PM
*To:* Linda Dunbar ; Yingzhen Qu 
; lsr@ietf.org

*Cc:* lsr-cha...@ietf.org
*Subject:* Re: IP layer metrics collected by Edge routers - 
draft-dunbar-lsr-5g-edge-compute-ospf-ext (was: LSR Presentation Slot 
request)


We seem to be in a circular discussion – we’re not standardizing 
loosely-defined metrics that only work in limited domains for OSPF and 
IS-IS. It is not a question of where.


Acee

*From: *Linda Dunbar >

*Date: *Tuesday, July 13, 2021 at 3:42 PM
*To: *Acee Lindem mailto:a...@cisco.com>>, Yingzhen Qu 
mailto:yingzhen.i...@gmail.com>>, 
"lsr@ietf.org " mailto:lsr@ietf.org>>
*Cc: *"lsr-cha...@ietf.org " 
mailto:lsr-cha...@ietf.org>>
*Subject: *RE: IP layer metrics collected by Edge routers - 
draft-dunbar-lsr-5g-edge-compute-ospf-ext (was: LSR Presentation Slot 
request)


Acee,

Limited domain also needs IS-IS and OSPF  routing protocol (among 
routers in the limited domain). If not in LSR, where is the right place?


Linda

*From:* Acee Lindem (acee) mailto:a...@cisco.com>>
*Sent:* Tuesday, July 13, 2021 2:24 PM
*To:* Linda Dunbar >; Yingzhen Qu 
mailto:yingzhen.i...@gmail.com>>; lsr@ietf.org 


*Cc:* lsr-cha...@ietf.org 
*Subject:* Re: IP layer metrics collected by Edge routers - 
draft-dunbar-lsr-5g-edge-compute-ospf-ext (was: LSR Presentation Slot 
request)


Linda – we’re not doing routing for limited domains in LSR. It doesn’t 
make any sense to go any further until you fix the draft or abandon it.


Thanks,

Acee

*From: *Linda Dunbar >

*Date: *Tuesday, July 13, 2021 at 1:23 PM
*To: *Acee Lindem mailto:a...@cisco.com>>, Yingzhen Qu 
mailto:yingzhen.i...@gmail.com>>, 
"lsr@ietf.org " mailto:lsr@ietf.org>>
*Cc: *"lsr-cha...@ietf.org " 
mailto:lsr-cha...@ietf.org>>
*Subject: *RE: IP layer metrics collected by Edge routers - 
draft-dunbar-lsr-5g-edge-compute-ospf-ext (was: LSR Presentation Slot 
request)


Acee,

The scope of the draft is for IGP in the  Limited Domains per RFC8799, 
i.e. the small number of routers in the 5G 

[Lsr] Regarding draft-liu-lsr-p2poverlan

[Joel M. Halpern]

In earlier emails, we brought 
https://datatracker.ietf.org/doc/html/draft-liu-lsr-p2poverlan-02 to the 
attention of the working group.


This draft was written to provide an explanation of how the 303 ifType 
code point that was assigned at Ericsson's request could be used.  It 
builds on RFC 5309 as that example.  While that is not the only possible 
use for the ifType, it is the obvious one, which is why we brough this 
draft to the attention of the LSR working group.


Note that the code point was not assigned by RFC 5309.  The pointer in 
the IANA entry to 5309 was a simpler (probably too simple) of the 
explanation of "This code point can be used with that thing."  Which is 
why this draft also updates the IANA entry (assuming the draft becomes 
an Informational RFC) to point to the draft.


There were some useful comments about the document on thge list.  We 
have updated the document to address those.


There were also concerns expressed by two participants that the document 
is useless.  Obviously, we would not have written it if we thought it 
was useless :-)


Given that LSR is the most obvious consumer of the ifType code point 
(but not the owner of the registry), we were looking to work with the 
LSR working group to improve and advance this document.


If LSR considers this useless or uninteresting, then we will seek other 
ways of publicly documenting how the ifType code point can be used.


Yours,
Joel

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

Re: [Lsr] Fwd: I-D Action: draft-liu-lsr-p2poverlan-00.txt

[Joel M. Halpern]

Tom, please look at the latest revision and see if that helps.

Also note, this document does not assign the ifType. (I.e. it does not 
"create an ifType".)  That is already done.


Yours,
Joel

On 6/24/2021 7:27 AM, tom petch wrote:

From: Les Ginsberg (ginsberg) 
Sent: 23 June 2021 17:38

Joel -

I have had concerns from the beginning as to whether this draft is really 
needed.
As I have commented previously, the only content of any significance is Section 
4 - and that only provides example settings of the management fields for this 
interface type.
I question whether a draft is required for this purpose.
I will defer on this matter to folks more expert in this area than I, but, my 
opinion is that a draft solely for this purpose is not required.


Les has a point.  I see a relevant I-D and dive in and review it and do not 
stop to think whether or not this work justifies an RFC.  Having reviewed it, 
and having worked out what is new - as Les says, examples in Section 4 and not 
much else  - I struggle to see a justification.

The other thought that this brought to mind is why create an ifType value when 
the world has been getting on quite happily without it for 13 years?  Is there 
anything that now needs a value which previously did not?  If so, that might be 
more suitable for an I-D.

Tom Petch


I thought it polite to mention this before you spend the time and effort to 
produce a new version.

Les



-Original Message-
From: Lsr  On Behalf Of tom petch
Sent: Wednesday, June 23, 2021 1:43 AM
To: Joel M. Halpern ; Harold Liu
; lsr@ietf.org
Subject: Re: [Lsr] Fwd: I-D Action: draft-liu-lsr-p2poverlan-00.txt

From: Joel M. Halpern 
Sent: 22 June 2021 09:57

Do Les' suggested edits address your concerns.
We will apply yor changes to the IANA considerations section.


I would go further than Les as I suggested on Tuesday.  Perhaps it is time for
a new version to comment on.

Tom Petch

Yours,
Joel

On 6/22/2021 4:34 AM, tom petch wrote:

From: Joel M. Halpern 
Sent: 21 June 2021 15:13

Tom, 5309 did not define the ifType.  Go read 5309.  You seem to have
gotten confused by the fact that the IANA entry given to 303 points to
5309.  That was done to have some reference (with the consent of the
experts).   What we are doing now is providing a better reference.  So
yes, this document defines how the ifType is defined.  With no criticism
of 5309, it does not define that, since it does not define the ifType.


Stepping back a few e-mails,
I have read 5309 and did point out previously that there is no IANA

Considerations in that RFC.  What I have said and repeat here is that 5309
defines the p2pOverLan type.  That is what the RFC claims and that is what it
does.  You seem to think that the definition of a type is incomplete without a
numerical value assigned to it, the SMI ifType  or YANG identity.  The concept
of the type exists whether or not a value has been assigned to it and this is
one of the places where this I-D goes wrong..


I would say
Abstract
The p2pOverLan interface type is described in RFC5309.
Subsequently, this interface type has been assigned a value of 303 by

IANA, by Expert Review.

This memo 

Well, what does it do?  Gives examples of its use?  I see nothing more.

Tom Petch

We are explicit in this draft that one of the obvious uses for this
ifType is to trigger 5309 behavior.

Yours,
Joel

On 6/21/2021 4:41 AM, tom petch wrote:

From: Lsr  on behalf of Harold Liu



Sent: 21 June 2021 02:01

Hi Med and All:
  Thanks for your helpful comments, I have updated a new version 01

to follow the comments;

  The main updating is:
  1. More clearly described the intend of this draft in the 
introduction;
  2. Change the reference style;
  3. Refactor the reference section to make it more reasonable;
  4. I haven't change "IANA Consideration" at the moment given there

is lots of discussion in this part and it is still up in the air, I will change 
this
section next update the document once this part is finalized;



I still think that this is an unsatisfactory I-D and would oppose adoption in

its present form,


It is a question of veracity.  It claims to do what others have already done

and does so without reference, without acknowledgement.  Having the
same data defined in more than one place can only create confusion, in
future if not now.


This is a pattern and starts with the Abstract and continues throughout

the I-D.


Thus the Abstract claims 'this defines point-to-point interface type'.  No.

This type was defined in RFC5309 and you need to say that and to say what if
anything you are changing in that definition.  You should not reproduce text
from that RFC unless you have to and then you should make it clear you are
quoting.


You do the same with Figure 1.  This is a copy, may be accurate may be

not, it does not matter, from RFC8343 with no mention thereof.  You should
not be reproducing such

[Lsr] Fwd: I-D Action: draft-liu-lsr-p2poverlan-02.txt

[Joel M. Halpern]

We have submitted a revision which we hope addresses the comments we 
have received.  Further feedback is appreciated.


Yours,
Joel

PS: I think one of the effects of the changes is to better align the 
content with the intended informational status.  It should be clear now 
that it is informational.



 Forwarded Message 
Subject: I-D Action: draft-liu-lsr-p2poverlan-02.txt
Date: Thu, 24 Jun 2021 03:07:56 -0700
From: internet-dra...@ietf.org
Reply-To: internet-dra...@ietf.org
To: i-d-annou...@ietf.org


A New Internet-Draft is available from the on-line Internet-Drafts 
directories.



Title   : Interface Stack Table Definition for Point to 
Point (P2P) Interface over LAN

Authors : Daiying Liu
  Joel Halpern
  Congjie Zhang
Filename: draft-liu-lsr-p2poverlan-02.txt
Pages   : 5
Date: 2021-06-24

Abstract:
   In [RFC5309] defines the Point to Point (P2P) circuit type is one of
   the mainly used circuit types in link state routing protocol, and
   highlights it is important to identify the correct circuit type when
   forming adjacencies, flooding link state database packets, and
   monitor the link state.  This document adds Point to Point (P2P)
   Interface over LAN type (ifType) management stack tables mapping to
   provide benefit for operational control, maintenance and statistics.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-liu-lsr-p2poverlan/

There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-liu-lsr-p2poverlan-02

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-liu-lsr-p2poverlan-02


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


___
I-D-Announce mailing list
i-d-annou...@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

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

Re: [Lsr] Fwd: I-D Action: draft-liu-lsr-p2poverlan-00.txt

[Joel M. Halpern]

Do Les' suggested edits address your concerns.
We will apply yor changes to the IANA considerations section.

Yours,
Joel

On 6/22/2021 4:34 AM, tom petch wrote:

From: Joel M. Halpern 
Sent: 21 June 2021 15:13

Tom, 5309 did not define the ifType.  Go read 5309.  You seem to have
gotten confused by the fact that the IANA entry given to 303 points to
5309.  That was done to have some reference (with the consent of the
experts).   What we are doing now is providing a better reference.  So
yes, this document defines how the ifType is defined.  With no criticism
of 5309, it does not define that, since it does not define the ifType.


Stepping back a few e-mails,
I have read 5309 and did point out previously that there is no IANA 
Considerations in that RFC.  What I have said and repeat here is that 5309 
defines the p2pOverLan type.  That is what the RFC claims and that is what it 
does.  You seem to think that the definition of a type is incomplete without a 
numerical value assigned to it, the SMI ifType  or YANG identity.  The concept 
of the type exists whether or not a value has been assigned to it and this is 
one of the places where this I-D goes wrong..

I would say
Abstract
The p2pOverLan interface type is described in RFC5309.
Subsequently, this interface type has been assigned a value of 303 by IANA, by 
Expert Review.
This memo 

Well, what does it do?  Gives examples of its use?  I see nothing more.

Tom Petch

We are explicit in this draft that one of the obvious uses for this
ifType is to trigger 5309 behavior.

Yours,
Joel

On 6/21/2021 4:41 AM, tom petch wrote:

From: Lsr  on behalf of Harold Liu 

Sent: 21 June 2021 02:01

Hi Med and All:
 Thanks for your helpful comments, I have updated a new version 01 to 
follow the comments;
 The main updating is:
 1. More clearly described the intend of this draft in the introduction;
 2. Change the reference style;
 3. Refactor the reference section to make it more reasonable;
 4. I haven't change "IANA Consideration" at the moment given there is 
lots of discussion in this part and it is still up in the air, I will change this section 
next update the document once this part is finalized;


I still think that this is an unsatisfactory I-D and would oppose adoption in 
its present form,

It is a question of veracity.  It claims to do what others have already done 
and does so without reference, without acknowledgement.  Having the same data 
defined in more than one place can only create confusion, in future if not now.

This is a pattern and starts with the Abstract and continues throughout the I-D.

Thus the Abstract claims 'this defines point-to-point interface type'.  No.  
This type was defined in RFC5309 and you need to say that and to say what if 
anything you are changing in that definition.  You should not reproduce text 
from that RFC unless you have to and then you should make it clear you are 
quoting.

You do the same with Figure 1.  This is a copy, may be accurate may be not, it 
does not matter, from RFC8343 with no mention thereof.  You should not be 
reproducing such text without a good reason and then you should make it clear 
what is reproduced, from where and why.

And as I have said already, IANA Considerations is yet again claiming to do 
what has already happened which can only confuse.  All that is needed as I said 
in a separate note  is to ask IANA to update two references, nothing more.

Tom Petch

 And I would like to share more background information for this 
internet draft:
 As Joel mentioned, we requested and received an IF Type assignment 
from IANA (with expert review) for point-to-point over Ethernet links several 
weeks ago and the p2pOverLan type is already added to IANA registry now;
 During the discussion around the assignment we noticed a doc 
describing why that is needed and how to use that would be helpful;
 For example, if no entry saying p2pOverLan layer over ethernet, the 
management will suffer since lose the ability to get to the Ethernet-specific 
management properties (Ethernet MIB or YANG model) via many tools; So we 
propose this draft to define a complete p2pOverLan ifStack(Including higher 
layer and lower layer);

Brs

-Original Message-
From: mohamed.boucad...@orange.com 
Sent: Thursday, June 17, 2021 2:16 PM
To: Joel M. Halpern ; draft-liu-lsr-p2pover...@ietf.org
Subject: RE: [Lsr] Fwd: I-D Action: draft-liu-lsr-p2poverlan-00.txt

Hi Joel, all,

Please find some quick comments to this draft, fwiw:

* pdf: 
https://protect2.fireeye.com/v1/url?k=e8e7d1aa-b77ce948-e8e79131-86073b36ea28-edbd778070bbec9a=1=d4a020c9-b337-41fd-bf1b-56dcfaef1044=https%3A%2F%2Fgithub.com%2Fboucadair%2FIETF-Drafts-Reviews%2Fblob%2Fmaster%2Fdraft-liu-lsr-p2poverlan-00-rev%2520Med.pdf
* doc: 
https://protect2.fireeye.com/v1/url?k=938b5849-cc1060ab-938b18d2-86073b36ea28-e0406a2599fa2a6d=1=d4a020c9-b337-41fd-bf1b-56dcfaef104

Re: [Lsr] Fwd: I-D Action: draft-liu-lsr-p2poverlan-00.txt

[Joel M. Halpern]

Okay.  We will make those changes.

Thank you,
Joel

On 6/21/2021 3:06 PM, Les Ginsberg (ginsberg) wrote:

Joel -

In addition to the IANA section changes,

1)Please be sure that the text consistently refers to "Point to Point (P2P) Interface over 
LAN" - not simply "Point to Point"

2)I think the abstract/introduction should make it clear that this draft is specifying 
the management mappings for the " Point to Point (P2P) Interface over LAN".
It is NOT defining Point to Point (P2P) Interface over LAN operation - that 
clearly was already done by RFC 5309.

3)I don’t know if Section 3 is really needed. I tend to think not.
But if you do want to keep it, please Reference RFC 8343 Section 4 as this is 
clearly a copy of the Figure in that document/section.

Les




-Original Message-
From: Joel Halpern Direct 
Sent: Monday, June 21, 2021 8:47 AM
To: Les Ginsberg (ginsberg) ; tom petch
; Harold Liu
; lsr@ietf.org
Subject: Re: [Lsr] Fwd: I-D Action: draft-liu-lsr-p2poverlan-00.txt

The change Tom has proposed to the IANA considerations section is fine
with me.

If there are other specific changes that will make it clearer, I and my
co-authors are happy to make those.   I have tried looking at the text.
   Even before you found it misleading, I did conclude that Tom getting
the wrong impression meant it needs to be clarified.  But as I am having
trouble seeing what misled you, I can not suggest wording improvements
to my co-authors.

I presume from your phrasing that you want more changes than just to the
IANA considerations section.  I presume I am just being dense in not
seeing the rest.  I apologize, but that does not make me less dense.
Sorry.

Help?
Joel

On 6/21/2021 11:28 AM, Les Ginsberg (ginsberg) wrote:

Joel -

I am not objecting to the draft.
I am simply asking for it to be both clear and accurate in what it is actually

doing.


I think Tom has done an excellent job of pointing out the inaccuracies and

in some cases providing proposed revised text.


I would ask you to reread your own draft in the context that at least two

people have read it and found it inaccurate and both of us have made very
explicit points about what language is confusing.


 Les


-Original Message-
From: Joel Halpern Direct 
Sent: Monday, June 21, 2021 8:13 AM
To: Les Ginsberg (ginsberg) ; tom petch
; Harold Liu
; lsr@ietf.org
Subject: Re: [Lsr] Fwd: I-D Action: draft-liu-lsr-p2poverlan-00.txt

Les, I am missing something ion both your and Tom's comments.  5309
didn't define the ifType.  If you look at 5309, it has no IANA
considerations at all.

Yes, this document should talk about 5309 as one of the cases that the
ifType simplifies.  And it does.

This documents follows the lead of 8343 in defining this specific ifType.

Let's be clear.  We were asked, quite reasoanbly, by the expert, when we
requested the IANA code point, to please submit a document describing
how the dcode point would be used, rather than merely pointing at 5309
and assuming everyone could guess correctly.  (Guessing is not good for
standards.)
So we are trying to do so.

You seem to be objecting to our doing so.  Why?

If the working group really doesn't want a description, we can go away.
We have the code point we felt was useful.  But it seems much more
useful to actually provide meaningful documentation.

Yours,
Joel



On 6/21/2021 10:58 AM, Les Ginsberg (ginsberg) wrote:

I am in complete agreement with the points Tom has made.

AFAICT, the only new content in this draft is Section 4 - the rest is either

boilerplate or a repetition of text already present in RFC 5309 or RFC 8343.

Neither the Abstract nor the Introduction makes that clear.
The abstract actually claims to

   "defines point-to-point interface type"

which is both FALSE (already defined in RFC 5309) and incorrectly named

-

since the document is actually discussing "point-to-point operation over
LAN".


Regarding the IANA section, it is clear that the draft is NOT creating new

entries - rather it is modifying existing entries. And it isn’t modifying the

code

points, the names, or the descriptions - it only seeks to modify the
references to include "this document".

But the text in the IANA section states otherwise:

" IANA need to update the "Interface Types(ifType)" registry...with the

following status types"


I don’t know whether the content in Section 4 is sufficient to claim a

reference, but if it is it should only be in addition to the existing reference.


  Les


-Original Message-
From: Lsr  On Behalf Of Joel M. Halpern
Sent: Monday, June 21, 2021 7:13 AM
To: tom petch ; Harold Liu
; lsr@ietf.org
Subject: Re: [Lsr] Fwd: I-D Action: draft-liu-lsr-p2poverlan-00.txt

Tom, 5309 did not define the ifType.  Go read 5309.  You seem to have
gotten confused by the fact that the IANA entry given to 303 points to
5309.  That was done to have some r

Re: [Lsr] Fwd: I-D Action: draft-liu-lsr-p2poverlan-00.txt

[Joel M. Halpern]

Tom, 5309 did not define the ifType.  Go read 5309.  You seem to have 
gotten confused by the fact that the IANA entry given to 303 points to 
5309.  That was done to have some reference (with the consent of the 
experts).   What we are doing now is providing a better reference.  So 
yes, this document defines how the ifType is defined.  With no criticism 
of 5309, it does not define that, since it does not define the ifType.


We are explicit in this draft that one of the obvious uses for this 
ifType is to trigger 5309 behavior.


Yours,
Joel

On 6/21/2021 4:41 AM, tom petch wrote:

From: Lsr  on behalf of Harold Liu 

Sent: 21 June 2021 02:01

Hi Med and All:
Thanks for your helpful comments, I have updated a new version 01 to 
follow the comments;
The main updating is:
1. More clearly described the intend of this draft in the introduction;
2. Change the reference style;
3. Refactor the reference section to make it more reasonable;
4. I haven't change "IANA Consideration" at the moment given there is 
lots of discussion in this part and it is still up in the air, I will change this section 
next update the document once this part is finalized;


I still think that this is an unsatisfactory I-D and would oppose adoption in 
its present form,

It is a question of veracity.  It claims to do what others have already done 
and does so without reference, without acknowledgement.  Having the same data 
defined in more than one place can only create confusion, in future if not now.

This is a pattern and starts with the Abstract and continues throughout the I-D.

Thus the Abstract claims 'this defines point-to-point interface type'.  No.  
This type was defined in RFC5309 and you need to say that and to say what if 
anything you are changing in that definition.  You should not reproduce text 
from that RFC unless you have to and then you should make it clear you are 
quoting.

You do the same with Figure 1.  This is a copy, may be accurate may be not, it 
does not matter, from RFC8343 with no mention thereof.  You should not be 
reproducing such text without a good reason and then you should make it clear 
what is reproduced, from where and why.

And as I have said already, IANA Considerations is yet again claiming to do 
what has already happened which can only confuse.  All that is needed as I said 
in a separate note  is to ask IANA to update two references, nothing more.

Tom Petch

And I would like to share more background information for this internet 
draft:
As Joel mentioned, we requested and received an IF Type assignment from 
IANA (with expert review) for point-to-point over Ethernet links several weeks 
ago and the p2pOverLan type is already added to IANA registry now;
During the discussion around the assignment we noticed a doc describing 
why that is needed and how to use that would be helpful;
For example, if no entry saying p2pOverLan layer over ethernet, the 
management will suffer since lose the ability to get to the Ethernet-specific 
management properties (Ethernet MIB or YANG model) via many tools; So we 
propose this draft to define a complete p2pOverLan ifStack(Including higher 
layer and lower layer);

Brs

-Original Message-
From: mohamed.boucad...@orange.com 
Sent: Thursday, June 17, 2021 2:16 PM
To: Joel M. Halpern ; draft-liu-lsr-p2pover...@ietf.org
Subject: RE: [Lsr] Fwd: I-D Action: draft-liu-lsr-p2poverlan-00.txt

Hi Joel, all,

Please find some quick comments to this draft, fwiw:

* pdf: 
https://protect2.fireeye.com/v1/url?k=e8e7d1aa-b77ce948-e8e79131-86073b36ea28-edbd778070bbec9a=1=d4a020c9-b337-41fd-bf1b-56dcfaef1044=https%3A%2F%2Fgithub.com%2Fboucadair%2FIETF-Drafts-Reviews%2Fblob%2Fmaster%2Fdraft-liu-lsr-p2poverlan-00-rev%2520Med.pdf
* doc: 
https://protect2.fireeye.com/v1/url?k=938b5849-cc1060ab-938b18d2-86073b36ea28-e0406a2599fa2a6d=1=d4a020c9-b337-41fd-bf1b-56dcfaef1044=https%3A%2F%2Fgithub.com%2Fboucadair%2FIETF-Drafts-Reviews%2Fraw%2Fmaster%2Fdraft-liu-lsr-p2poverlan-00-rev%2520Med.docx

Cheers,
Med


-Message d'origine-
De : Lsr [mailto:lsr-boun...@ietf.org] De la part de Joel M. Halpern
Envoyé : mercredi 16 juin 2021 22:47 À : Acee Lindem (acee)
; lsr@ietf.org Objet : Re: [Lsr] Fwd: I-D Action:
draft-liu-lsr-p2poverlan-00.txt

This document (and the code point) are intended to be in line with
5309.
   I believe they are.  If we got it wrong, please help us fix it.

A reference would be reasonable to add.  (The IANA entry for the code
point does reference 5309.)

Thank you,
Joel



On 6/16/2021 4:41 PM, Acee Lindem (acee) wrote:

Hi Joel,

At first I wondered where this document should reside and then

decided that LSR is probably as good as any other place.


Can you guys check whether it is mostly in line with

https://datatracker.ietf.org/doc/rfc5309/ and comment as to whether it
should be referenced?


Thanks,
Acee


On 6/16/21, 11:10 AM, "Lsr on b

Re: [Lsr] Fwd: I-D Action: draft-liu-lsr-p2poverlan-00.txt

[Joel M. Halpern]

How can we clarify the wording.  If it is misleading you, we need to 
improve it.   The text is not asking to create an entry (i.e. it does 
not "ask for an assignment"), but rather to change an entry that already 
exists.  (And obviously, it won't do so until and if the document 
becomes an RFC.)


Yours,
Joel

On 6/18/2021 12:20 PM, tom petch wrote:

From: Joel M. Halpern 
Sent: 18 June 2021 16:29

Tom, I am not sure what you mean by "the update has happened">  The code
point has been assigned.  Assuming this document becomes an RFC, it will
be significantly clearer if the 303 code point IANA entry points at this
for information instead of 5309.  So this document requests that update.


I mean that the IANA Registry has been updated to include 303 with a reference 
to 5309 so I think it wrong of this I-D to ask for assignment which is what I 
see it doing with

IANA need to update the "Interface Types(ifType)"  with the following status 
types:

   |  303|  p2pOverLan  |Point to Point over LAN interface  |

  It should only ask for the reference to be changed and should also spell out 
that the assignment was made by Expert Review since that may otherwise be 
unclear to users..

Likewise the update to the YANG module is automatic, has happened and so 
specifying it here can only confuse IMHO.

And elsewhere I find the flavour misleading.  The abstract and introduction 
should IMHO reference RFC5309 as the source of p2pOverLan, add that the values 
have been assigned by Expert Review and that this I-D ... well I am not clear 
what it does except lay claim to things that others have already done with 
RFC5309 and expert review :-)

I think too that camel case is problematic.  SMI uses it, YANG does not but we 
are now likely stuck with identity p2pOverLan .

Tom Petch

Yours,
Joel

On 6/18/2021 7:47 AM, tom petch wrote:

From: Lsr  on behalf of Joel M. Halpern 

Sent: 16 June 2021 21:46

This document (and the code point) are intended to be in line with 5309.
I believe they are.  If we got it wrong, please help us fix it.

A reference would be reasonable to add.  (The IANA entry for the code
point does reference 5309.)


which confused me as RFC5309 has no IANA considerations and no reference to 
303.  I understand how this is so but think that this I-D could explain this.  
I think that the I-D is wrong to ask IANA to perform an update - the update has 
happened.

What would help would be for this I-D to explain that the allocation was made 
by Expert Review and to ask that IANA update the reference to point to this I-D 
and then this I-D can point back to RFC5309.  This is almost an updates to 5309 
as it give a value to the specification - I can see the IESG having fun with 
that concept but I would go for it.

I think too that this I-D should reference and build on RFC5309.  At present it 
looks like an Unused Ref.

Tom Petch



Thank you,
Joel



On 6/16/2021 4:41 PM, Acee Lindem (acee) wrote:

Hi Joel,

At first I wondered where this document should reside and then decided that LSR 
is probably as good as any other place.

Can you guys check whether it is mostly in line with 
https://datatracker.ietf.org/doc/rfc5309/ and comment as to whether it should 
be referenced?

Thanks,
Acee


On 6/16/21, 11:10 AM, "Lsr on behalf of Joel M. Halpern"  wrote:

   Recently, Ericsson requested and received an IF Type assignment from
   IANA (with expert review) for point-to-point over Ethernet links.

   It was noted during the discussion around the assignment that a document
   (eventually, we hope, an RFC) describing how to use that and why we
   asked for it would be helpful.

   The below announcement is that draft.  We would like to work with the
   community to improve and clarify teh draft.

   Thank you,
   Joel


    Forwarded Message 
   Subject: I-D Action: draft-liu-lsr-p2poverlan-00.txt
   Date: Wed, 16 Jun 2021 07:00:04 -0700
   From: internet-dra...@ietf.org
   Reply-To: internet-dra...@ietf.org
   To: i-d-annou...@ietf.org


   A New Internet-Draft is available from the on-line Internet-Drafts
   directories.


Title   : Interface Stack Table Definition for Point to
   Point (P2P) Interface over LAN
Authors : Daiying Liu
  Joel Halpern
  Congjie Zhang
Filename: draft-liu-lsr-p2poverlan-00.txt
Pages   : 7
Date: 2021-06-16

   Abstract:
   The point-to-point circuit type is one of the mainly used circuit
   types in link state routing protocol.  It is important to identify
   the correct circuit type when forming adjacencies, flooding link
   state database packets, and monitor the link state.  This document
   defines point-to-poi

Re: [Lsr] Fwd: I-D Action: draft-liu-lsr-p2poverlan-00.txt

[Joel M. Halpern]

Tom, I am not sure what you mean by "the update has happened">  The code 
point has been assigned.  Assuming this document becomes an RFC, it will 
be significantly clearer if the 303 code point IANA entry points at this 
for information instead of 5309.  So this document requests that update.


Yours,
Joel

On 6/18/2021 7:47 AM, tom petch wrote:

From: Lsr  on behalf of Joel M. Halpern 

Sent: 16 June 2021 21:46

This document (and the code point) are intended to be in line with 5309.
   I believe they are.  If we got it wrong, please help us fix it.

A reference would be reasonable to add.  (The IANA entry for the code
point does reference 5309.)


which confused me as RFC5309 has no IANA considerations and no reference to 
303.  I understand how this is so but think that this I-D could explain this.  
I think that the I-D is wrong to ask IANA to perform an update - the update has 
happened.

What would help would be for this I-D to explain that the allocation was made 
by Expert Review and to ask that IANA update the reference to point to this I-D 
and then this I-D can point back to RFC5309.  This is almost an updates to 5309 
as it give a value to the specification - I can see the IESG having fun with 
that concept but I would go for it.

I think too that this I-D should reference and build on RFC5309.  At present it 
looks like an Unused Ref.

Tom Petch



Thank you,
Joel



On 6/16/2021 4:41 PM, Acee Lindem (acee) wrote:

Hi Joel,

At first I wondered where this document should reside and then decided that LSR 
is probably as good as any other place.

Can you guys check whether it is mostly in line with 
https://datatracker.ietf.org/doc/rfc5309/ and comment as to whether it should 
be referenced?

Thanks,
Acee


On 6/16/21, 11:10 AM, "Lsr on behalf of Joel M. Halpern"  wrote:

  Recently, Ericsson requested and received an IF Type assignment from
  IANA (with expert review) for point-to-point over Ethernet links.

  It was noted during the discussion around the assignment that a document
  (eventually, we hope, an RFC) describing how to use that and why we
  asked for it would be helpful.

  The below announcement is that draft.  We would like to work with the
  community to improve and clarify teh draft.

  Thank you,
  Joel


   Forwarded Message 
  Subject: I-D Action: draft-liu-lsr-p2poverlan-00.txt
  Date: Wed, 16 Jun 2021 07:00:04 -0700
  From: internet-dra...@ietf.org
  Reply-To: internet-dra...@ietf.org
  To: i-d-annou...@ietf.org


  A New Internet-Draft is available from the on-line Internet-Drafts
  directories.


   Title   : Interface Stack Table Definition for Point to
  Point (P2P) Interface over LAN
   Authors : Daiying Liu
 Joel Halpern
 Congjie Zhang
   Filename: draft-liu-lsr-p2poverlan-00.txt
   Pages   : 7
   Date: 2021-06-16

  Abstract:
  The point-to-point circuit type is one of the mainly used circuit
  types in link state routing protocol.  It is important to identify
  the correct circuit type when forming adjacencies, flooding link
  state database packets, and monitor the link state.  This document
  defines point-to-point interface type and relevant stack tables to
  provide benefit for operation, maintenance and statistics.


  The IETF datatracker status page for this draft is:
  https://datatracker.ietf.org/doc/draft-liu-lsr-p2poverlan/

  There is also an htmlized version available at:
  https://datatracker.ietf.org/doc/html/draft-liu-lsr-p2poverlan-00


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


  ___
  I-D-Announce mailing list
  i-d-annou...@ietf.org
  https://www.ietf.org/mailman/listinfo/i-d-announce
  Internet-Draft directories: http://www.ietf.org/shadow.html
  or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

  ___
  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] Fwd: I-D Action: draft-liu-lsr-p2poverlan-00.txt

[Joel M. Halpern]

This document (and the code point) are intended to be in line with 5309. 
 I believe they are.  If we got it wrong, please help us fix it.


A reference would be reasonable to add.  (The IANA entry for the code 
point does reference 5309.)


Thank you,
Joel



On 6/16/2021 4:41 PM, Acee Lindem (acee) wrote:

Hi Joel,

At first I wondered where this document should reside and then decided that LSR 
is probably as good as any other place.

Can you guys check whether it is mostly in line with 
https://datatracker.ietf.org/doc/rfc5309/ and comment as to whether it should 
be referenced?

Thanks,
Acee


On 6/16/21, 11:10 AM, "Lsr on behalf of Joel M. Halpern"  wrote:

 Recently, Ericsson requested and received an IF Type assignment from
 IANA (with expert review) for point-to-point over Ethernet links.

 It was noted during the discussion around the assignment that a document
 (eventually, we hope, an RFC) describing how to use that and why we
 asked for it would be helpful.

 The below announcement is that draft.  We would like to work with the
 community to improve and clarify teh draft.

 Thank you,
 Joel


  Forwarded Message 
 Subject: I-D Action: draft-liu-lsr-p2poverlan-00.txt
 Date: Wed, 16 Jun 2021 07:00:04 -0700
 From: internet-dra...@ietf.org
 Reply-To: internet-dra...@ietf.org
 To: i-d-annou...@ietf.org


 A New Internet-Draft is available from the on-line Internet-Drafts
 directories.


  Title   : Interface Stack Table Definition for Point to
 Point (P2P) Interface over LAN
  Authors : Daiying Liu
Joel Halpern
Congjie Zhang
Filename: draft-liu-lsr-p2poverlan-00.txt
Pages   : 7
Date: 2021-06-16

 Abstract:
 The point-to-point circuit type is one of the mainly used circuit
 types in link state routing protocol.  It is important to identify
 the correct circuit type when forming adjacencies, flooding link
 state database packets, and monitor the link state.  This document
 defines point-to-point interface type and relevant stack tables to
 provide benefit for operation, maintenance and statistics.


 The IETF datatracker status page for this draft is:
 https://datatracker.ietf.org/doc/draft-liu-lsr-p2poverlan/

 There is also an htmlized version available at:
 https://datatracker.ietf.org/doc/html/draft-liu-lsr-p2poverlan-00


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


 ___
 I-D-Announce mailing list
 i-d-annou...@ietf.org
 https://www.ietf.org/mailman/listinfo/i-d-announce
 Internet-Draft directories: http://www.ietf.org/shadow.html
 or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

 ___
 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] Fwd: I-D Action: draft-liu-lsr-p2poverlan-00.txt

[Joel M. Halpern]

Recently, Ericsson requested and received an IF Type assignment from 
IANA (with expert review) for point-to-point over Ethernet links.


It was noted during the discussion around the assignment that a document 
(eventually, we hope, an RFC) describing how to use that and why we 
asked for it would be helpful.


The below announcement is that draft.  We would like to work with the 
community to improve and clarify teh draft.


Thank you,
Joel


 Forwarded Message 
Subject: I-D Action: draft-liu-lsr-p2poverlan-00.txt
Date: Wed, 16 Jun 2021 07:00:04 -0700
From: internet-dra...@ietf.org
Reply-To: internet-dra...@ietf.org
To: i-d-annou...@ietf.org


A New Internet-Draft is available from the on-line Internet-Drafts 
directories.



Title   : Interface Stack Table Definition for Point to 
Point (P2P) Interface over LAN

Authors : Daiying Liu
  Joel Halpern
  Congjie Zhang
Filename: draft-liu-lsr-p2poverlan-00.txt
Pages   : 7
Date: 2021-06-16

Abstract:
   The point-to-point circuit type is one of the mainly used circuit
   types in link state routing protocol.  It is important to identify
   the correct circuit type when forming adjacencies, flooding link
   state database packets, and monitor the link state.  This document
   defines point-to-point interface type and relevant stack tables to
   provide benefit for operation, maintenance and statistics.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-liu-lsr-p2poverlan/

There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-liu-lsr-p2poverlan-00


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


___
I-D-Announce mailing list
i-d-annou...@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

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

Re: [Lsr] Erik Kline's Discuss on draft-ietf-lsr-isis-srv6-extensions-14: (with DISCUSS)

[Joel M. Halpern]

I have been watching this debate, and I am left with the impression that 
the information being defined in section 9 of this draft is simply not 
useful for routing.   It confuses operational information with routing 
information.  Given taht the information has to come from somewhere 
outside the router anyway, iand that it is not going to be consumed by 
the routers who receive the advertisements, why is it here?


Yours,
Joel

On 5/20/2021 7:49 AM, Peter Psenak wrote:

Hi Erik,

thanks for your comment, please see inline:

On 19/05/2021 03:58, Erik Kline via Datatracker wrote:

Erik Kline has entered the following ballot position for
draft-ietf-lsr-isis-srv6-extensions-14: 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 DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-srv6-extensions/



--
DISCUSS:
--

[ section 9 ]

* I share the concerns of several of the others here about SRv6 SIDs 
being

   claimed to be IPv6 addresses but kinda not really being IPv6 addresses
   if their internal structure is exposed outside of the given SR router.



SRv6 SIDs are indeed IPv6 addresses. RFC8986 introduced the SRv6 SID 
structure. It also goes into allocation of SIDs where it describes the 
carving out of the Block for SRv6 SIDs in the domain, followed by the 
allocation of SRv6 Locators to the nodes in the domain. Then the node 
allocates the function part when instantiating the SID - and all of this 
is signaled via control plane protocols. This is all exposed and know to 
the operator who determines the addressing scheme.





   If "[i]t's usage is outside of the scope of this document", can 
this be
   removed for now, and maybe take up the issue at some point in the 
future

   by which time a motivating use case might have presented itself?



The use-cases have not been described in this document since they were 
out of the scope of the ISIS protocol operations. Some of the use-cases 
discussed have been :


- automation and verification of blocks/locators and setup of filtering 
for them at SR domain boundaries


- validation of SRv6 SIDs being instantiated and advertised via IGP; 
these can be learnt by apps/controllers via BGP-LS and then monitored 
for conformance to the addressing rules set by the operator.


- verification and even determination of summary routes to be used for 
covering the SRv6 Locators and SIDs.


There may be other use-cases that may be operator or vendor specific. 
The use-cases are not within the scope of ISIS protocol extensions and 
are either operational or implementation specific – hence we said it was 
out of the scope of this document.


If you feel adding these to the document may help to clear your 
concerns, I can certainly add them.


thanks,
Peter














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


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

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

[Joel M. Halpern]

I have read this draft, and followed the discussion on the list.
This seems a useful and sensible piece of work.  I support adoption.

Yours,
Joel

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


Thanks,

Acee


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



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

Re: [Lsr] Pre-writeup review comments

[Joel M. Halpern]

Just to confirm, yes, that change Peter has made removing END.T resolves 
my concerns.

Thanks,
Joel

On 10/8/2020 9:38 AM, Peter Psenak wrote:

Hi Chris,

please see inline:

On 02/10/2020 12:32, Christian Hoppsprotocol= application/pgp-signature 
wrote:

Thanks for the update, a couple issues remain.

[ ] 7.1 and 8.1

The reserved bits for "SRv6 Locator TLV" and "SRv6 End.X SID sub-TLV" are
defined differently (and probably incorrectly) than the other reserved 
bits.

Reserved bits "MUST" be set to zero, not "SHOULD", I believe.


fixed.



[ ] 11.  Implementation Status

I know you mentioned that the section should be removed, but how about 
adding a note to the editor in the next revision e.g., "RFC Ed.: 
Please remove this section prior to publication"?


done



[ ] 12.5.  Sub-Sub-TLVs for SID Sub-TLVs

This section needs to better conform to registry creation standards (see
https://tools.ietf.org/html/rfc8126). In particular there is no guidance.


I have modified the section 12.5.




It looks like there is more discussion from Joel on this draft, so I 
will hold off on submission for that to resolve.


I have removed the END.T in the latest version. The discussion with Joel 
is closed.


thanks,
Peter



Thanks,
Chris.

On Sep 23, 2020, at 4:36 PM, Peter Psenak 
 wrote:


Hi Chris,

thanks for your comments.

Please see inline (##PP):

On 18/09/2020 16:08, Christian Hoppsprotocol= 
application/pgp-signature wrote:
During my review and while doing the Shepherd writeup for 
https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-srv6-extensions/ I 
came up with the following comments:

4.3 - Maximum H.Encaps MSD Type:
   - what is the default if not advertised?


##PP
added "or no value is advertised" as for other MSD types.


6.  Advertising Anycast Property
Should "Locator that is advertised..." be:
   "An SRv6 Locator that is advertised..."?
or:
   "A prefix/SRv6 Locator that is advertised..."?


##PP
fixed.


7.1 SRv6 Locator TLV Format
The R fields and their handling, are not defined.


##PP
added



8.  Advertising SRv6 Adjacency SIDs
"must be" "in order to be correctly applied" -> "are" and ""?


##PP
I replaced with:

Certain SRv6 Endpoint behaviors 
[I-D.ietf-spring-srv6-network-programming] are associated with a 
particular adjacency.




8.1.  SRv6 End.X SID sub-TLV
"Other bits" -> "Reserved bits" -- labels should match


##PP
fixed.


8.2.  SRv6 LAN End.X SID sub-TLV
I'm sympathetic to Bruno's comment, and so I think it would be 
better to say:

Diagram: "System ID (1-6 octets)" and in text:
"6 octets" -> "System ID: 1-6 octets"
I see no reason to mess with this even if the commonly-implemented 
value is 6 at
this point. IS-IS implementations that only support 6 octets are 
free to only
support 6 in this sub-TLV as well. They won't be talking with other 
IS-IS
routers that are configured to have a non-6 octet system ID value. 
What other
extension RFCs may or may-not do WRT this doesn't really matter I 
think.


##PP
I have updated the text to match what is being used in RFC8667, 
section 2.2.2




"Other bits" -> "Reserved bits" -- labels should match


##PP
fixed


11.  Implementation Status
Does this section need a "RFC Ed.: Please Remove prior to 
publications"? It
seems pretty wrong to document current status of implementations 
permanently in

an Standards Track RFC.


##PP
yes this section will be removed prior to publication. This is a 
standard procedure we follow.



12. IANA Considerations
An odd space between "sub- TLV".


##PP
fixed


12.5.  Sub-Sub-TLVs for SID Sub-TLVs
This section needs to better conform to registry creation standards 
(see

https://tools.ietf.org/html/rfc8126).


##PP
I updated the IANA section format similar to RFC8667.



ID-NITS:
   There are 19 instances of too long lines in the document, the 
longest one

   being 5 characters in excess of 72.


##PP
fixed.


References:
   Normative:
 Published: RFC 8754 draft-6man-segment-routing-header


##PP
fixed.



 Out of date reference: [I-D.ietf-6man-spring-srv6-oam]
 Out of date reference: [I-D.ietf-spring-srv6-network-programming]


##PP
Whenever the new version of draft-ietf-lsr-isis-srv6-extension is 
published it picks the latest version, but as these drafts keep 
changing the reference may get out of date quickly.





   Informative:
 Published: RFC 8402 draft-ietf-spring-segment-routing


##PP
fixed

thanks,
Peter

___
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] New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt

[Joel M. Halpern]

I am missing something in this discussion of multiple algorithms.

My understanding of flex-algo whether for MPLS, SRv6, SRH, or IPv6, is 
that you need to associated a forwarding label (e.g. MPLS label or IPv6 
address) with a specific algorithm so that you can compute the next hope 
for the forwarding label using the proper algorithm.  Then when a packet 
arrives, it is simply forwarded according to the forwarding table (e.g. 
FIB, LIB, ..)


If that is so, then I do not understand how a given prefix can be safely 
associated with more than one algorithm.  I could imagine doing several 
calculations according to different algorithms.  But how do you decide 
which one applies to the packet?  As far as I know, flex-algo does not 
look at the QoS/CoS/ToS bits.


Yours,
Joel

PS: I will admit that it took until  an operator described some 
"interesting" constraints before I understood why one would even do this.


On 9/29/2020 11:50 PM, Huzhibo wrote:

Hi.

Associating multiple algorithms with a given prefix is an interesting topic, 
and I think this can simplify the complexity of FlexAlgo. I wonder if the 
author would consider using cases with multiple algorithms with a given prefix.

Thanks

ZHibo

-Original Message-
From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of tony...@tony.li
Sent: Tuesday, September 29, 2020 10:05 PM
To: Ron Bonica 
Cc: lsr@ietf.org
Subject: Re: [Lsr] New Version Notification for 
draft-bonica-lsr-ip-flexalgo-00.txt


Ron,

This is nice. It makes it clear that constraint based path computation need not 
have MPLS overhead for those that don’t want it.

One thing that you don’t talk about is how this gets used, tho that may be 
blindingly obvious: you’ll need all nodes placing their prefixes in the 
RIB/FIB, where it will need to be selected over other path computation for the 
same prefixes.  This somewhat precludes the possibility of a given prefix being 
useful in multiple flex-algos.

More text on application would be most welcome, just to ensure that we’re on 
the same page.

Tony



On Sep 29, 2020, at 6:37 AM, Ron Bonica  
wrote:


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-bo
nica-lsr-
ip-flexalgo/__;!!NEt6yMaO-gk!X7PVDP-
FnUA0oCcZMw3Qde6in0C72hu_9hOZ53kPspIarR8fNDyU9Vck8x7e5ZqI$
Htmlized:
https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/dra
ft-
bonica-lsr-ip-flexalgo__;!!NEt6yMaO-gk!X7PVDP-
FnUA0oCcZMw3Qde6in0C72hu_9hOZ53kPspIarR8fNDyU9Vck82w_6CyU$
Htmlized:   https://urldefense.com/v3/__https://tools.ietf.org/html/draft-
bonica-lsr-ip-flexalgo-00__;!!NEt6yMaO-gk!X7PVDP-
FnUA0oCcZMw3Qde6in0C72hu_9hOZ53kPspIarR8fNDyU9Vck81_QrJ_p$


Abstract:
   An IGP Flexible Algorithm computes a constraint-based path and maps
   that path to an identifier.  As currently defined, Flexalgo can only
   map the paths that it computes to Segment Routing (SR) identifiers.
   Therefore, Flexalgo cannot be deployed in the absence of SR.

   This document extends Flexalgo, so that it can map the paths that it
   computes to IP addresses.  This allows Flexalgo to be deployed in any
   IP network, even in the absence of SR.




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 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] I-D Action: draft-ietf-lsr-isis-srv6-extensions-10.txt - END.T

[Joel M. Halpern]

Thanks for the clarifications to Peter and Ketan.  (I now understand 
what I missed about the control for END.DT2M.)


It seems that as currently laid out, the document appears to define the 
encoding for END.T, but does not provide enough information to use it?


Which suggests that we should either improve it or remove it.
The inclusion of END.T in the network programming draft means that 
removing it will leave a gap with us standardizing the meaning of END.T 
but not the control to communicate it.  That seems better than a partial 
definition of how to communicate it.


Yours,
Joel

On 9/29/2020 4:39 AM, Peter Psenak wrote:

Joel, Ketan,

On 28/09/2020 15:25, Ketan Talaulikar (ketant) wrote:

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.


ARG is part of the SID. The fact that it is not used currently by any 
SID that is defined for ISIS, does not mean the ARG part of the SID does 
not exists. We advertise the SID as 128 bits in ISIS, so we ARG is part 
of it.




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.


draft-ietf-spring-srv6-network-programming only defines ARG for END.DT2M.

We can certainly say in ISIS draft that for the SIDs defined in it, 
there are no ARGs.




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.


I would tend to remove the END.T from the ISIS draft. If we need it, we 
could define it in a separate document.


thanks,
Peter



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

Re: [Lsr] I-D Action: draft-ietf-lsr-isis-srv6-extensions-10.txt

[Joel M. Halpern]

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.


If so, should we say explicitly that ARG is (or MUST be) 0 for all the 
behaviors defined in this draft?


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?


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?


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 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"  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

Re: [Lsr] I-D Action: draft-ietf-lsr-isis-srv6-extensions-10.txt

[Joel M. Halpern]

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.


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.


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).


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.


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"  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: 2020-09-23
 >
 > Abstract:
 > Segment Routing (SR) allows for a flexible definition of end-to-end
 > paths by encoding paths as sequences of topological sub-paths, called
 > "segments".  Segment routing architecture can be implemented over an
 > MPLS data plane as well as an IPv6 data plane.  This draft describes
 > the IS-IS extensions required to support Segment Routing over an IPv6
 > data plane.
 >
 >

 ___
 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] Flooding across a network

[Joel M. Halpern]

Les, maybe I am missing your point, but it sounds like what you are 
asking for is a (better?) version of the micro-loop prevention work, so 
as to mitigate the interaction between inconsistent convergence and 
fast-reroute?


Yours,
Joel

On 5/6/2020 1:53 PM, Les Ginsberg (ginsberg) wrote:

Bruno -

I am sorry it has been so difficult for us to understand each other. I am 
trying my best.

Look at it this way:

You are the customer. 
I am the vendor.

The failure scenario I describe below happens and you notice that all 
Northbound destinations loop for 35 seconds whenever fast flooding is enabled.
I think you are going to complain about this - to me. 

And I am going to tell you that this is a consequence of enabling fast flooding 
in the presence of a node which does not support it. Your options to reduce the 
period of looping will be:

1)Upgrade the slow node to support faster flooding
2)Disable fast flooding
3)Redesign your network

 Les


-Original Message-
From: bruno.decra...@orange.com 
Sent: Wednesday, May 06, 2020 10:10 AM
To: Christian Hopps 
Cc: Les Ginsberg (ginsberg) ; lsr@ietf.org
Subject: RE: [Lsr] Flooding across a network


From: Christian Hopps [mailto:cho...@chopps.org]

Bruno persistence has made me realize something fundamental here.

The minute the LSP originator changes the LSP and floods it you have LSDB

inconsistency.

Exactly my point. Thank you Chris.
I would even say: "The minute the LSP originator changes the LSP then you
have LSDB inconsistency." But no big deal if there is disagreement on this
detail.


That is going to last until the last node in the network has updated it's LSDB.


Absolutely.
So the faster we flood, the shorter the LSBD inconsistency.

Now IMO, even if a single/few nodes flood faster, there is a chance of
shortening the LSDB inconsistency. But in all cases, I don't see how this could
make the LSDB inconsistency longer.



Les is pointing out that LSDB inconsistency can be bad in certain

circumstances e.g., if a critical node is slow and thus inconsistent.


I believe the right way to fix this is a simple one, help the operator flag the

broken router software/hardware for replacement, but otherwise IS-IS
should just try to do the best job it can do to which is to flood around the
problem (i.e., flood as optimally as possible).

+1
On a side note, I would not call a router flooding slowly as "broken". I find it
understandable that in a given network there are different type of routers
(core vs aggregation), different roles (P having 50 IGP adjacencies with 50 PEs
vs PE having only 2 IGP adjacencies with 2 P), different hardware
generations, different software, different vendors with different
perspectives/markets.

Thank you Chris.

--Bruno


Thanks,
Chris.
[as WG member]



On May 6, 2020, at 10:33 AM, bruno.decra...@orange.com wrote:

Les,

From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com]
Sent: Wednesday, May 6, 2020 4:14 PM
To: DECRAENE Bruno TGI/OLN
Cc: lsr@ietf.org
Subject: RE: Flooding across a network

Bruno –

I am somewhat at a loss to understand your comments.
The example is straightforward and does not need to consider FIB update

time nor the ordering of prefix updates on different nodes.

[Bruno] The example is straightforward but you are referring to FIB and IP

packets forwarding as per those FIBs.

I’d like we focus on LSP flooding and LSDB consistency.

Consider the state of Node B and Node D at various time points from the

trigger event.


T+ 2 seconds:
-
B has received all LSP Updates. It triggers an SPF and for all Northbound

destinations previously reachable via C it installs paths via D.

Let’s assume it take 5 seconds to update the forwarding plane.

D has received 40 of the 1000 LSP updates. It triggers an SPF and finds

that all Northbound destinations are reachable via B-C. It makes no changes
to the forwarding plane.


T+7 seconds
-
B has completed FIB updates. Traffic to all Northbound destinations is

being forwarded via D.


D has now received 140 of the 1000 LSP updates. Entries in its forwarding

plane for Northbound destinations still point to B.


We have a loop.

T + 30 seconds

D has now received 600 of the 1000 LSP updates. Still no changes to its

forwarding plane.

Traffic to Northbound destinations is still looping.

T+ 50 seconds
---
D has finally received all 1000 LSP updates..
It triggers (another) SPF and calculates paths to Northbound destinations

via E. It begins to update its forwarding plane.

Let’s assume this will take 5 seconds..

T + 55 seconds

D has completed forwarding plane updates – no more looping.

That is all I am trying to illustrate.

If you want to start arguing that node protecting LFAs + microloop

avoidance could help (NOTE I explicitly  took those out of the example for
simplicity) – it is easy enough to change the example to include multiple node
failures or a node failure 

Re: [Lsr] A new version of I-D, draft-liu-lsr-isis-ifit-node-capability-02

[Joel M. Halpern]

Robert, you seem to be asking that we pass full information about the 
dynamic network state to all routers so that they can, if needed, serve 
as fully intelligent path computation engines.  If you want to do that, 
you will need more than just the telemetry.  You will need the demands 
that are coming in to all of those routers, so that you can make global 
decisions sensibly.

Which is why we use quasi-centralized path computation engines.

Yours,
Joel

On 4/2/2020 6:16 PM, Robert Raszuk wrote:


 > If you consider such constrains to provide reachability for
applications you will likely see value that in-situ telemetry is
your friend here. Really best friend as without him you can not do
the proper end to end path exclusion for SPT computations..

[as wg member] Are you thinking that shifting traffic to a router is
not going to affect it's jitter/drop rate?


Well this is actually the other way around.

First you have your default topology. They you are asked to 
construct new one based on applied constrains.


So you create complete TE coverage and start running end to end data 
plane probing over all TE paths (say SR-TE for specific example). Once 
you start collecting the probe results you can start excluding paths 
which do not meet your applied constraints. And that process continues.


To your specific question - It is not that unusual where routers degrade 
their performance with time and in many cases the traffic is not the 
cause for it but internal bugs and malfunctions.


Best,
R.

___
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] Using IS-IS Multi-Topology (MT) for Segment Routing based Virtual Transport Network

[Joel M. Halpern]

Chongfeng, it would be very helpful to see a draft that actually 
described the problems you need addressed.  I believe there are changes 
we need to make to improve things.e  But the current problem statement 
draft is so vague that it does not help me understand what problem you 
actually need to solve.  Which then leaves me unable to match the 
proposals in this draft to any specific needs.


Yours,
Joel

On 3/27/2020 5:19 AM, xie...@chinatelecom.cn wrote:


Joel,
Thank you for your comments.
 From the pespective of an operator, new services need more support from 
underlay network, such as network resource and connection support. 
Considering the limition of MPLS-TE, we think that new mechanisms should 
be introduced into underlay network to meet the requirements of services.


Best regards
Chongfeng


中国电信股份有限公司研究院
+86-10-50902116


*From:* Joel M. Halpern <mailto:j...@joelhalpern.com>
*Date:* 2020-03-26 21:35
*To:* xie...@chinatelecom.cn <mailto:xie...@chinatelecom.cn>; lsr
<mailto:lsr@ietf.org>
*Subject:* Re: [Lsr] Using IS-IS Multi-Topology (MT) for Segment
Routing based Virtual Transport Network
In once sense, the statement is inherently true.  A VPN technology
without underlay support would seem to have significant difficulty in
consistently meeting an SLA.  Having said that much, the rest does not
seem to follow.
Yours,
Joel
On 3/26/2020 1:40 AM, xie...@chinatelecom.cn wrote:
 >
 > Hi, Joel,
 >
 > The statement is that pure overlay VPNs cannot meet the
requirement of
 > some new services, and it would require integration between the
underlay
 > and the overlay networks.
 >
 > As mentioned in this document, there is existing technology in the
 > underlay to support enhanced VPNs , such as using a set of
MPLS-TE based
 > resource reserved point-to-point paths, while it scalability is the
 > concern of many operators.
 >
 > Thus VTN is introduced to provide the required topology and resource
 > attribute in the underlay in a scalable manner. This is described
in the
 > introduction section.
 >
 > Hope this helps.
     >
 >
 > Chongfeng
 >
 >
 > *From:* Joel M. Halpern <mailto:j...@joelhalpern.com>
 > *Date:* 2020-03-25 21:52
 > *To:* xie...@chinatelecom.cn <mailto:xie...@chinatelecom.cn>; lsr
 > <mailto:lsr@ietf.org>
 > *Subject:* Re: [Lsr] Using IS-IS Multi-Topology (MT) for Segment
 > Routing based Virtual Transport Network
 > This drafts starts by asserting that there are limitations on
what can
 > be done with the existing technology.  As the description is
quite
 > vague, I can not be certain.  But I do not know of any
difficulty in
 > providing the described capabilities with current technology,
without
 > introducing a new, undescribed, construct called a VTN.
 > Yours,
 > Joel
 > On 3/25/2020 9:44 AM, xie...@chinatelecom.cn wrote:
 >  >
 >  > Hello, folks,
 >  >
 >  > we have submitted a new draft of
 >  > 
  https://tools.ietf.org/html/draft-xie-lsr-isis-sr-vtn-mt-00 .

 >  >
 >  > It is about Using IS-IS Multi-Topology (MT) for Segment
Routing
 > based
 >  > Virtual Transport Network. Enhanced VPN (VPN+) as defined in
 >  > I-D.ietf-teas-enhanced-vpn aims to provide enhanced VPN
service to
 >  > support some applications's needs of enhanced isolation and
 > stringent
 >  > performance requirements.  VPN+ requries integration
between the
 > overlay
 >  > VPN and the underlay network.  A Virtual Transport Network
(VTN)
 > is a
 >  > virtual network which consists of a subset of the network
toplogy
 > and
 >  > network resources allocated from the underlay network.  A VTN
 > could be
 >  > used as the underlay for one or a group of VPN+ services..
This
 > document
 >  > describes a simplified mechanism to build the SR based
VTNs using
 > IGP
 >  > multi- topology together with other well-defined IS-IS
extensions.
 >  >
 >  > Comments and suggestions are highly appreciated.
 >  >
 >  > Chongfeng Xie
 >  >
 >  >
 >  >
 >  > ___
 >  > Lsr mailing list
 >  > Lsr@ietf.

Re: [Lsr] Using IS-IS Multi-Topology (MT) for Segment Routing based Virtual Transport Network

[Joel M. Halpern]

In once sense, the statement is inherently true.  A VPN technology 
without underlay support would seem to have significant difficulty in 
consistently meeting an SLA.  Having said that much, the rest does not 
seem to follow.


Yours,
Joel

On 3/26/2020 1:40 AM, xie...@chinatelecom.cn wrote:


Hi, Joel,

The statement is that pure overlay VPNs cannot meet the requirement of 
some new services, and it would require integration between the underlay 
and the overlay networks.


As mentioned in this document, there is existing technology in the 
underlay to support enhanced VPNs , such as using a set of MPLS-TE based 
resource reserved point-to-point paths, while it scalability is the 
concern of many operators.


Thus VTN is introduced to provide the required topology and resource 
attribute in the underlay in a scalable manner. This is described in the 
introduction section.


Hope this helps.


Chongfeng


*From:* Joel M. Halpern <mailto:j...@joelhalpern.com>
*Date:* 2020-03-25 21:52
*To:* xie...@chinatelecom.cn <mailto:xie...@chinatelecom.cn>; lsr
<mailto:lsr@ietf.org>
*Subject:* Re: [Lsr] Using IS-IS Multi-Topology (MT) for Segment
Routing based Virtual Transport Network
This drafts starts by asserting that there are limitations on what can
be done with the existing technology.  As the description is quite
vague, I can not be certain.  But I do not know of any difficulty in
providing the described capabilities with current technology, without
introducing a new, undescribed, construct called a VTN.
Yours,
Joel
On 3/25/2020 9:44 AM, xie...@chinatelecom.cn wrote:
 >
 > Hello, folks,
 >
 > we have submitted a new draft of
 >   https://tools.ietf.org/html/draft-xie-lsr-isis-sr-vtn-mt-00 .
 >
 > It is about Using IS-IS Multi-Topology (MT) for Segment Routing
based
 > Virtual Transport Network. Enhanced VPN (VPN+) as defined in
 > I-D.ietf-teas-enhanced-vpn aims to provide enhanced VPN service to
 > support some applications's needs of enhanced isolation and
stringent
 > performance requirements.  VPN+ requries integration between the
overlay
 > VPN and the underlay network.  A Virtual Transport Network (VTN)
is a
 > virtual network which consists of a subset of the network toplogy
and
 > network resources allocated from the underlay network.  A VTN
could be
 > used as the underlay for one or a group of VPN+ services.. This
document
 > describes a simplified mechanism to build the SR based VTNs using
IGP
 > multi- topology together with other well-defined IS-IS extensions.
 >
 > Comments and suggestions are highly appreciated.
 >
 > Chongfeng Xie
 >
 >
 >
 > ___
 > 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] Using IS-IS Multi-Topology (MT) for Segment Routing based Virtual Transport Network

[Joel M. Halpern]

This drafts starts by asserting that there are limitations on what can 
be done with the existing technology.  As the description is quite 
vague, I can not be certain.  But I do not know of any difficulty in 
providing the described capabilities with current technology, without 
introducing a new, undescribed, construct called a VTN.


Yours,
Joel

On 3/25/2020 9:44 AM, xie...@chinatelecom.cn wrote:


Hello, folks,

we have submitted a new draft of 
  https://tools.ietf.org/html/draft-xie-lsr-isis-sr-vtn-mt-00 .


It is about Using IS-IS Multi-Topology (MT) for Segment Routing based 
Virtual Transport Network. Enhanced VPN (VPN+) as defined in 
I-D.ietf-teas-enhanced-vpn aims to provide enhanced VPN service to 
support some applications's needs of enhanced isolation and stringent 
performance requirements.  VPN+ requries integration between the overlay 
VPN and the underlay network.  A Virtual Transport Network (VTN) is a 
virtual network which consists of a subset of the network toplogy and 
network resources allocated from the underlay network.  A VTN could be 
used as the underlay for one or a group of VPN+ services. This document 
describes a simplified mechanism to build the SR based VTNs using IGP 
multi- topology together with other well-defined IS-IS extensions.


Comments and suggestions are highly appreciated.

Chongfeng Xie



___
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] "Legal" endpoint behaviors [draft-ietf-lsr-isis-srv6-extensions-06.txt]

[Joel M. Halpern]

It does seem to me that using a registry to capture the relationship 
between the OSPF or IS-IS advertisement (TLV, sub-TLV, ...) and the SR 
behavior (as defined in the NP registry and subsequent additions) is 
useful.  I would not want to have to respin the base draft to add 
additional behaviors.  We use registries for a reason.


Now, if the advertisement registry has a note column, we could use that 
to record the information.  As far as I know the current registries are 
not well-structured for such auxiliary information.


Yours,
Joel

On 3/11/2020 11:52 AM, Christian Hopps wrote:




On Mar 11, 2020, at 10:38 AM, Les Ginsberg (ginsberg) 
 wrote:

Chris -




Do you think we should get rid of the "used in" columns in the IS-IS TLV and
sub-TLV registries? The documents that define those TLVs and sub-TLVs
already indicate which PDUs and TLVs they go in, so why do we need that
info in the registry?


[Les:] The difference for me is that the definition of sub-TLVs associated with 
the related set of TLVs is scattered across multiple RFCs. The additional 
information in the registry allows us to find this information in one place.
Here, there is only one relevant IS-IS draft on this technology (SRv6). If the 
set of behaviors which can be advertised in IS-IS changes, then an additional 
IS-IS document (or a bis) will be written - and it likely would be required for 
other reasons.

We still may not agree - but I hope we at least understand each other better.


Is the SR network programming document expected to respin a -bis for adding a 
behavior?

Anyway, unless someone else thinks this is important, I guess we can just 
revisit it when the next SR End behavior gets added and we're faced with 
re-spinning this document, the OSPF companion document, and whatever other 
protocols support documents for advertising the new behavior, in order to 
support it (rather than e.g., it just going directly in a base document or a 
combined protocols document and updating a couple registries).

Thanks,
Chris.
[as WG member]


   Les

___
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