Re: [Isis-wg] [Bier] BAR field length in draft-ietf-bier-isis-extensions and draft-ietf-bier-ospf-extensions

[Dolganow, Andrew (Nokia - SG/Singapore)]

Alia,

As per below i am not aware of a commercial deployment.

Some  implementation assume ability to use BIER specific algorithm. So if we 
keep 8 bits only, the IANA registry needs to allow that.  The registry being 
suggested as an option on the list will not allow BIER specific option ( and 
does not even support experimental bits at all) That would create a functional 
conflict unless the registry we use is BIER specific. But, as I pointed out, 
this option does not satisfy others.

Extending field as per Option B would require implementation change but can be 
accommodated but technically satisfies everyone’s needs I believe.

Andrew

Sent from my iPhone

On Feb 20, 2018, at 4:34 PM, Senthil Dhanaraj 
mailto:senthil.dhana...@huawei.com>> wrote:

I’m not aware of any commercial (or sort of) deployments.

So I hope it’s early enough for the implementations to adjust - Just like the 
consensus we had on the other issue related to allowing 0 as a valid value for 
“label-range (now called as “max-si)” which in-fact had a interoperability 
issue for last SI.

I do understand/agree there would be backward/interop issue with older bier-igp 
drafts if we make a change (say option-B) now for BAR.
Peter Psenak / Ice – Comments ?

Thanks,
Senthil


From: Alia Atlas [mailto:akat...@gmail.com]
Sent: 20 February 2018 10:45
To: Senthil Dhanaraj 
mailto:senthil.dhana...@huawei.com>>
Cc: BIER WG mailto:b...@ietf.org>>; 
isis-wg@ietf.org list 
mailto:isis-wg@ietf.org>>
Subject: RE: [Bier] BAR field length in draft-ietf-bier-isis-extensions and 
draft-ietf-bier-ospf-extensions

I have one additional question for those with implementations or testing them.

What is the impact of going with your preferred option in terms of 
interoperability?  It may be early enough that changes can happen, but more 
feedback is needed.

For those favoring Option B, could you send email to the list providing exact 
text so we have the details?

For those favoring the current status without an IANA registry, are you able to 
handle one being imposed during IESG Review?  It is an obvious concern to 
raise.  Are you just prolonging or postponing the discussion?

Regards,
Aka



On Feb 19, 2018 11:53 PM, "Senthil Dhanaraj" 
mailto:senthil.dhana...@huawei.com>> wrote:
+1 to Option-B
Seems future proof to me.

Thanks,
Senthil



From: BIER [mailto:bier-boun...@ietf.org] On 
Behalf Of Alia Atlas
Sent: 20 February 2018 03:21
To: BIER WG mailto:b...@ietf.org>>; 
isis-wg@ietf.org list 
mailto:isis-wg@ietf.org>>
Subject: [Bier] BAR field length in draft-ietf-bier-isis-extensions and 
draft-ietf-bier-ospf-extensions

As the Sponsoring AD for draft-ietf-bier-isis-extensions-07 and 
draft-ietf-bier-ospf-extensions-12, I have been following the discussion on the 
mailing list with interest.

I have not seen clear consensus for any change.

Let me be clear on what I see the options are from the discussion.  Then I'll 
elaborate
a bit on how you can express your perspective most usefully.

1) Current Status:  Bier Algorithm (BAR) field is 8 bits.  Currently, only 
value 0 is specified.  The drafts do not have an IANA registry - with the 
expectation that one will be created when the first additional use is clear.  
It is possible that there will be objections from the IESG to progressing 
without an IANA registry.  Given the lack of clarity for future use-cases and 
after discussion, I decided not to force one after my AD review - but I will 
not push back against having a BIER IANA registry if raised by others.

2) Option B:  Add a BAR sub-type of 8 bits.  This would modify the current TLVs.
   Define an IANA registry for the BAR type.  The meaning of the BAR sub-type 
derives
   from the BAR type.   We can debate over the registration policy for the BAR 
type.

3) Option C: Change the BAR field to be 16 bits and define an IANA registry.  
Part of the range can be FCFS with Expert Review, part can be Specification 
Required, and part can be IETF Consensus.

4) Option D: At some point in the future, if there is an actual understood and 
documented need, a BAR sub-type could be added a sub-TLV.  The length of the 
BAR sub-type could be determined when the sub-TLV is defined.

Given

  a) option D exists
  b) there is currently only one defined value for BAR
  c) I do not see strong consensus for change to one particular other option

I see no current reason for a change and I certainly see absolutely no reason 
for
a delay in progressing the documents.

I do want to be clear about what the WG wants to do on this issue.  Therefore, 
here is
my following request.

Please send your feedback to the mailing list as follows:

IF you prefer or can accept the current status, please say so.  No more 
justification
or reasoning is required. I just don't want the bulk of folks who are content 
to be
overlooked by those suggesting change.

IF you prefer or can accept the current status, b

Re: [Isis-wg] [Bier] BAR field length in draft-ietf-bier-isis-extensions and draft-ietf-bier-ospf-extensions

[Dolganow, Andrew (Nokia - SG/Singapore)]

All,

As we discussed here (as a WG) and in this topic:

  *   We need to have ability to define way for independent BIER computation 
algorithms (for BIER specific computations or other use cases, some of which 
Alia highlighted in her email below)
  *   We want to have extensibility to use other non-BIER specific algorithms 
(as others brought up)

The original draft can be argued not to provide both of those capabilities, and 
thus Option A below (marked as Current status) really just defers the issue. I 
find Option E that Ice added also counterproductive as it eliminates the top 
use case above. Thus we really left with options B, C, D as a compromise. From 
those, Option B seems to me the best:

  *   It meets the requirements above
  *   It allows a clean implementation (as opposed to Option C which is a bit 
more kludgy). Thanks to a sub-TLV defining what BAR field carries – a 
BIER-specific algorithm defined in BIER specific registry (a registry that 
should be BIER specific, regardless of IGP used), or something else to meet 
needs expressed by others, we meet the requirements from those who wanted to 
change the Current status

Option C/D are acceptable alternatives; however, Option B seems technically 
cleanest, most flexible, and meeting all requirements.

Andrew


From: Isis-wg  on behalf of Alia Atlas 

Date: Tuesday, February 20, 2018 at 12:05 PM
To: "(Ice) IJsbrand Wijnands" 
Cc: BIER WG , "isis-wg@ietf.org list" 
Subject: Re: [Isis-wg] [Bier] BAR field length in 
draft-ietf-bier-isis-extensions and draft-ietf-bier-ospf-extensions

Ice,

On Mon, Feb 19, 2018 at 7:57 PM, IJsbrand Wijnands 
mailto:i...@cisco.com>> wrote:
Alia,


I appreciate that you have finally decided to discuss this on the BIER mailing 
list.

I know that there are individual drafts draft-ppsenak-ospf-sr-flex-algo-00  and 
 draft-hegdeppsenak-isis-sr-flex-algo-02.
I see a bit of discussion on the is-is mailing list and at IETF 100, but, of 
course, no WG adoption.

I see BIER as a fundamental technology that can be used in different 
situations.  For instance, there is not merely
discussion of how Babel and BIER could interact - but actual code (thanks 
Sandy!); of course, that is not a WG-adopted
draft yet either, so this is merely a thought experiment example.  How do the 
different algorithms
work for an IGP that isn't link-state?   What about the ideas around using BIER 
with caches?  Are there issues there?
What about algorithms that make sense for BIER or multicast - but not for 
unicast?

IANA registries are not price prohibitive.  Why would we tie BIER to the 
link-state IGP registry?

We are talking about what needs to be advertised in OSPF and ISIS in order to 
select the BIER underlay. We are not discussing Babel or any other candidate 
underlay technologies for BIER. Moreover, we are not limiting any new 
innovation with BIER regarding the underlay. This discussion is strictly 
related to the drafts in the title.

I do not hear you making a technical argument.

This is an architectural argument!

An architectural argument can't also limit itself to the drafts in the title.

If it sounded like the IANA registry was suggested as separate for BIER OSPF  
and BIER ISIS, then your attempt to reframe the conversation might be 
reasonable.  Let me clarify - I see no current reason for an OSPF BAR registry 
and an ISIS BAR registry; it would just be a BAR registry.  Perhaps
that clarification is a good reason to get the IANA registry included in the 
next update?

The routing layer is separate from the BIER layer.  The BAR is for the BIER 
layer.

Regards,
Alia


Hope this clarifies,

Thx,

Ice.



Regards,
Alia


On Mon, Feb 19, 2018 at 7:03 PM, IJsbrand Wijnands 
mailto:i...@cisco.com>> wrote:
Hi Alia,

There is one more option that I think is not fully covered from the choice of 
options related to getting a registry.

The topic of the discussion is what information we need to pass in the IGP in 
order for BIER to select the correct underlay. What identifies the underlay is 
really what ever information is needed to select the Table (MT-ID) and 
Algorithm. An example of Algorithm work that is going on is Flex-Algo. My 
preferred option is to align with what ever the IGPs are using to identify the 
Algorithm.

Option E: Change BAR into “IGP Algorithm” registry as documented in 
https://www.iana.org/assignments/igp-parameters/igp-parameters.xhtml#igp-algorithm-types

Thx,

Ice.


On 19 Feb 2018, at 13:51, Alia Atlas 
mailto:akat...@gmail.com>> wrote:

As the Sponsoring AD for draft-ietf-bier-isis-extensions-07 and 
draft-ietf-bier-ospf-extensions-12, I have been following the discussion on the 
mailing list with interest.

I have not seen clear consensus for any change.

Let me be clear on what I see the options are from the discussion.  Then I'll 
elaborate
a bit on how you can express your perspective most usefully.

1) Current Status:  Bier Algorithm (BAR) field is 8 bits.  Currently, only 
value 0 is specified. 

Re: [Isis-wg] [Bier] WGLC : draft-ietf-bier-isis-extensions-07.txt

[Dolganow, Andrew (Nokia - SG/Singapore)]

Agree, what Eric has is starting to look like a compromise. Let’s get the final 
text (wip) on the list asap.

Andrew

From: "Les Ginsberg (ginsberg)" 
Date: Friday, February 16, 2018 at 11:08 PM
To: Eric Rosen , Andrew Dolganow 
, "(Ice) IJsbrand Wijnands" 
Cc: Greg Shepherd , "b...@ietf.org" , 
"isis-wg@ietf.org" , Xiejingrong , 
Arkadiy Gulko 
Subject: RE: [Bier] [Isis-wg] WGLC : draft-ietf-bier-isis-extensions-07.txt

Eric -

From: Eric C Rosen [mailto:ero...@juniper.net]
Sent: Friday, February 16, 2018 6:45 AM
To: Les Ginsberg (ginsberg) ; Dolganow, Andrew (Nokia - 
SG/Singapore) ; IJsbrand Wijnands 
Cc: Greg Shepherd ; b...@ietf.org; isis-wg@ietf.org; 
Xiejingrong ; arkadiy.gu...@thomsonreuters.com
Subject: Re: [Bier] [Isis-wg] WGLC : draft-ietf-bier-isis-extensions-07.txt

Perhaps the following would be a good compromise (or perhaps not).

Have an eight-bit field whose values are taken from the "IGP Algorithms" 
Registry.

Have another eight-bit field whose values are taken from a new BIER-specific 
registry.  I don't know, maybe call it the "BIER Underlay Algorithm Modifier" 
registry.  The way the underlay paths are computed for a given BIER sub-domain 
is determined by the pair of codepoints: .


[Les:] Makes sense – except I would think only when the BUAM == 0 do the values 
come from IGP registry. Other values for BUAM would require a different set of 
definitions for the algorithm value.
   Les

The default value for the "BIER Underlay Algorithm Modifier" field would be 
zero.   The value zero in this field would mean "just use the IGP Algorithms 
field to figure out how the underlay paths are computed."  Non-zero values 
could be used to add additional nuance.  Existing drafts can say "the use of 
non-zero values in this field is outside the scope of this document".

The registration policy for the new registry could save about  half the values 
for "standards action", and about half for FCFS.  And a few for Experimental.  
(This would be a good policy for the IGP Algorithms registry as well, imho.)

This seems to have minimal impact on existing implementations, and leaves room 
for further development of BIER while avoiding entanglements (or peceived 
entanglements) with other technologies that might be considered controversial.

Now perhaps the WG can proceed to the really important issues, such as how to 
best design the T-shirts.  (Though frankly I'd rather get a few more 
home-brewed beers than a T-shirt.)



On 2/16/2018 12:51 AM, Les Ginsberg (ginsberg) wrote:
Andrew –

There is no change being considered to the size of the algorithm field for 
Segment Routing.  That is 8 bits – there are mature SR documents and multiple 
implementations that use that encoding. There is also the IGP registry defined 
in an SR document (though not necessarily exclusively for SR use) which defines 
8 bit values.

The only thing which is being discussed here is whether BIER should use an 8 
bit or 16 bit algorithm field. Also, even if it is decided BIER should use a 16 
bit algorithm, it is conceivable that the values defined in the IGP algorithm 
registry may still be of use to BIER.

   Les

From: BIER [mailto:bier-boun...@ietf.org] On Behalf Of Dolganow, Andrew (Nokia 
- SG/Singapore)
Sent: Thursday, February 15, 2018 7:39 PM
To: IJsbrand Wijnands <mailto:i...@cisco.com>
Cc: Greg Shepherd <mailto:gjs...@gmail.com>; 
b...@ietf.org<mailto:b...@ietf.org>; isis-wg@ietf.org<mailto:isis-wg@ietf.org>; 
Xiejingrong <mailto:xiejingr...@huawei.com>; 
arkadiy.gu...@thomsonreuters.com<mailto:arkadiy.gu...@thomsonreuters.com>; Eric 
C Rosen <mailto:ero...@juniper.net>
Subject: Re: [Bier] [Isis-wg] WGLC : draft-ietf-bier-isis-extensions-07.txt

Well,

Now, there are multiple treads being discussed here under one topic:

- how big should the the field be?
- should there be common registry for all technologies?
- where should it be defined and which WG should standardize it?

To me the first question is totally dependent on the answer to the last two, 
since the use case pointed out suggests a common registry.

Now there may be different opinions (I believe there are from this exchange) 
whether we should or should not have a common registry, how complicated would 
it be and whether it would tax all groups trying to use that. But even before 
we go there, the basic question has to be answered:
- which WG would own that registry. It is not in a charter of BIER to own it 
nor it is in a charter of SR nor it is in a charter of ISIS. Do none of them 
should own and mandate use. We are chartering LSR now - should we add registry 
for all IGP algorithms, we have routing WG, others?  Would like to hear AD’s 
opinion. Note that although LSR appears obvious, the algorithms to compute BIER 
may be controller-based that do bot require LSR (same applies to SR).

- if we do a

Re: [Isis-wg] [Bier] WGLC : draft-ietf-bier-isis-extensions-07.txt

[Dolganow, Andrew (Nokia - SG/Singapore)]

Well,

Now, there are multiple treads being discussed here under one topic:

- how big should the the field be?
- should there be common registry for all technologies?
- where should it be defined and which WG should standardize it?

To me the first question is totally dependent on the answer to the last two, 
since the use case pointed out suggests a common registry.

Now there may be different opinions (I believe there are from this exchange) 
whether we should or should not have a common registry, how complicated would 
it be and whether it would tax all groups trying to use that. But even before 
we go there, the basic question has to be answered:
- which WG would own that registry. It is not in a charter of BIER to own it 
nor it is in a charter of SR nor it is in a charter of ISIS. Do none of them 
should own and mandate use. We are chartering LSR now - should we add registry 
for all IGP algorithms, we have routing WG, others?  Would like to hear AD’s 
opinion. Note that although LSR appears obvious, the algorithms to compute BIER 
may be controller-based that do bot require LSR (same applies to SR).

- if we do agree to have a common registry, I would assume we all then tax 
everyone to signal that the same way. That would mean changes to SR and changes 
to BIER.

This seems a lot. We have implementations of both technologies, so are changes 
to those warranted or is it too late and we should pursue independent  alg 
definition and registry as it has been set-up in the existing drafts. And we 
are talking only of those two but more WG will come and want to define things 
for them as well.


Andrew

Sent from my iPhone

On Feb 16, 2018, at 2:51 AM, IJsbrand Wijnands 
mailto:i...@cisco.com>> wrote:

I think its clear from the discussion there are different opinions on the 
matter on how to make BIER use the BAR field. The reason for me to support 16 
bits is that everybody seemed ok go move forward with an 8bits BAR without a 
registry, a 16bits BAR does not change anything, its just a bigger field. But 
at least with 16bits, we can split in Type, Value, and support different 
use-cases. IMO, pointing to whatever the Unicast underlay is providing is the 
main use-case, but it allows other ways to do things.

One thing is clear, with just 8bits, it will be very hard to reach an agreement 
what the registry would look like. If we make it 16bits, we know we can solve 
multiple use-cases. The main question (I think) is whether we document how a 
16bit BAR is carved up now, or we defer that to later. And as I said, since 
everybody seemed ok with 8bit BAR without a registry, I don’t see why its now 
different for 16bits. It gives us time to workout exactly how to use it and get 
input from the WGs.

And, of course, the goal is to create a registry for the 16 bits through a new 
draft!

Thx,

Ice.


On 15 Feb 2018, at 18:28, Tony Przygienda 
mailto:tonysi...@gmail.com>> wrote:



On Thu, Feb 15, 2018 at 9:20 AM, Greg Shepherd 
mailto:gjs...@gmail.com>> wrote:
On Thu, Feb 15, 2018 at 8:53 AM, Tony Przygienda 
mailto:tonysi...@gmail.com>> wrote:


On Thu, Feb 15, 2018 at 8:38 AM, Greg Shepherd 
mailto:gjs...@gmail.com>> wrote:
For the record, there is no SR Registry. There is only an IGP Algo Type 
Registry as defined in draft-ietf-ospr-segment-routing-extensions-24 section 8.5

So is that a good idea, having multiple drafts in flight with fields expecting 
to have magic couplings to each other while leaving e'thing "unspecified" to 
"publish RFCs" while we "decide things later"?

That was a pivot, but still; there is no reference, there is no coupling.

Tangental: draft-ietf-ospr-segment-routing-extensions-24 has been around for a 
while, and the IGP Algo registry will be tied to this draft and it's fate. If 
anyone is expecting to use this registry outside of the scope of this draft, it 
would be in their best interest to pull the registry description out into a 
separate draft.


OK, and I agree that if such a registry is pulled and under a clear charter of 
mandating multiple technologies within an independent body then a discussion 
starts to make sense and what the size of that should be given that mandates 
algorithms over multiple technologies (SR, unicast, mcast, whatever) and 
implies a "God's eye view" of all the elements of all the technologies (and if 
a computation touches elements from two technologies they become [optionally] 
coupled).  We are not talking IGP registry or multicast computation registry or 
SR registry then but a "wider scope registry". Yes, that is an intriguing 
thought with its own validity but outside the scope of charter we're under as 
BIER.  Personally, I consider multiple, if needed loosely coupled registries 
for each technology a less centralized and hence "more Internet like" solution 
but I see how opinions on such a thing can diverge ...

thanks

--- tony



___
BIER mailing list
b...@ietf.org
https

Re: [Isis-wg] [Bier] WGLC : draft-ietf-bier-isis-extensions-07.txt

[Dolganow, Andrew (Nokia - SG/Singapore)]

Guys,

I would think 8 bits are sufficient. Others (like SegRtg mentioned below also 
use 8). 8 bits gives us tons of room to grow - especially since we have only a 
single value defined currently (SFP 0). If we have clear use cases that show us 
running out of 8 bits or getting close to that we can/should discuss and 
evaluate extensions in light of that but increasing the space "just in case" is 
not a prudent way to go.

Andrew

-Original Message-
From: BIER  on behalf of Xiejingrong 

Date: Wednesday, February 14, 2018 at 5:06 PM
To: Arkadiy Gulko , "b...@ietf.org" 
, "isis-wg@ietf.org" 
Subject: Re: [Bier] WGLC : draft-ietf-bier-isis-extensions-07.txt

Hi Arkadiy,

I checked the latest  and 
 for reference and comparing, 
and they both use a 8 bits Algorithm.
One of the description: "Algorithm: Single octet identifying the algorithm."

Interesting to use more than 8 bits for BIER's future flexibility :-)

Regards,
XieJingrong


-Original Message-
From: BIER [mailto:bier-boun...@ietf.org] On Behalf Of 
arkadiy.gu...@thomsonreuters.com
Sent: Wednesday, February 14, 2018 8:42 AM
To: b...@ietf.org; isis-wg@ietf.org
Subject: [Bier] WGLC : draft-ietf-bier-isis-extensions-07.txt

Hello Working Group,
After initial discussions between multiple participants of the working 
group, we consolidated that BIER's future flexibility would be well served if 
we extend the IGP signaling BAR field to 16 bits. We are currently reviewing 
various use-cases that can greatly benefit from this enhancement.
I would appreciate if the proposed change could be considered as part of 
IETF Last Call review.
Thanks,
Arkadiy


-Original Message-
From: BIER [mailto:bier-boun...@ietf.org] On Behalf Of 
internet-dra...@ietf.org
Sent: Friday, February 09, 2018 5:11 PM
To: i-d-annou...@ietf.org
Cc: b...@ietf.org
Subject: [Bier] I-D Action: draft-ietf-bier-isis-extensions-07.txt


A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Bit Indexed Explicit Replication WG of the 
IETF.

Title   : BIER support via ISIS
Authors : Les Ginsberg
  Tony Przygienda
  Sam Aldrin
  Jeffrey (Zhaohui) Zhang
Filename: draft-ietf-bier-isis-extensions-07.txt
Pages   : 10
Date: 2018-02-09

Abstract:
   Specification of an ISIS extension to support BIER domains and sub-
   domains.



The IETF datatracker status page for this draft is:

https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dbier-2Disis-2Dextensions_&d=DwICAg&c=4ZIZThykDLcoWk-GVjSLmy8-1Cr1I4FWIvbLFebwKgY&r=JA6g2ZDvIPLQHZqHQByKQq-jvOcxu4cQskARppQFqZc&m=TOz3rr3No8ReKzE_27M4FMDvmv6fa9xveuyL5HyTvYs&s=3qPmQav_QUBjHi7KygPVk9bIhVZ7TL2Z3xfHOo_Cjwc&e=
 

There are also htmlized versions available at:

https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dbier-2Disis-2Dextensions-2D07&d=DwICAg&c=4ZIZThykDLcoWk-GVjSLmy8-1Cr1I4FWIvbLFebwKgY&r=JA6g2ZDvIPLQHZqHQByKQq-jvOcxu4cQskARppQFqZc&m=TOz3rr3No8ReKzE_27M4FMDvmv6fa9xveuyL5HyTvYs&s=_nTFvlAW24snrkMm3aQ2uWLFsLCajYeW4HO3DdEiwvs&e=

https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_html_draft-2Dietf-2Dbier-2Disis-2Dextensions-2D07&d=DwICAg&c=4ZIZThykDLcoWk-GVjSLmy8-1Cr1I4FWIvbLFebwKgY&r=JA6g2ZDvIPLQHZqHQByKQq-jvOcxu4cQskARppQFqZc&m=TOz3rr3No8ReKzE_27M4FMDvmv6fa9xveuyL5HyTvYs&s=zHWCGuyM-GSX-slbFtCv4fs9ml5gPQBeXohosuyhpx4&e=
 

A diff from the previous version is available at:

https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_rfcdiff-3Furl2-3Ddraft-2Dietf-2Dbier-2Disis-2Dextensions-2D07&d=DwICAg&c=4ZIZThykDLcoWk-GVjSLmy8-1Cr1I4FWIvbLFebwKgY&r=JA6g2ZDvIPLQHZqHQByKQq-jvOcxu4cQskARppQFqZc&m=TOz3rr3No8ReKzE_27M4FMDvmv6fa9xveuyL5HyTvYs&s=pDVWzZrYzGia4WKiA_cSF0P5isUmMeojSvHJIGgdOTk&e=
 


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

Internet-Drafts are also available by anonymous FTP at:

https://urldefense.proofpoint.com/v2/url?u=ftp-3A__ftp.ietf.org_internet-2Ddrafts_&d=DwICAg&c=4ZIZThykDLcoWk-GVjSLmy8-1Cr1I4FWIvbLFebwKgY&r=JA6g2ZDvIPLQHZqHQByKQq-jvOcxu4cQskARppQFqZc&m=TOz3rr3No8ReKzE_27M4FMDvmv6fa9xveuyL5HyTvYs&s=wqMqmybm38ZiX4CuzJaNJPMea1Mf-pSgD-vdgAHk850&e=
 

___
BIER mailing list
b...@ietf.org

https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_bier&d=DwICAg&c=4ZIZThykDLcoWk-GVjSLmy8-1Cr1I4FWIvbLFebwKgY&r=JA6g2ZDvIPLQHZqHQByKQq-jvOcxu4cQskARppQFqZc&m=TOz3rr3No8ReKzE_2

Re: [Isis-wg] Link-State Routing WG charter

[Dolganow, Andrew (Nokia - SG/Singapore)]

One comment – I would add a bit of text at the end of the below-quoted sentence 
to ensure that “extensions planned to meet the needs” do not create 
stability/performance problems to IGPs. I proposed a text in red for that:

The Link-State Routing (LSR) Working Group will coordinate with other working 
groups, such as RTGWG, SPRING, MPLS, TEAS, V6OPS, and 6MAN, to understand the 
need for extensions and to confirm that the planned work meets the needs and is 
compatible with both IS-IS and OSPF from functional, architectural and 
performance point of views

Andrew

From: Isis-wg  on behalf of Alia Atlas 

Date: Thursday, January 25, 2018 at 1:19 AM
To: "isis-wg@ietf.org" , OSPF List 
Subject: [Isis-wg] Link-State Routing WG charter

Here is the proposed charter for the LSR working group
that will be created from the SPF and ISIS working groups.

This is scheduled for internal review for the IESG telechat on February 8.

https://datatracker.ietf.org/doc/charter-ietf-lsr/

The Link-State Routing (LSR) Working Group is chartered to document current 
protocol implementation practices and improvements, protocol usage scenarios, 
maintenance and extensions of link-state routing interior gateway protocols 
(IGPs) with a focus on IS-IS, OSPFv2, and OSPFv3.  The LSR Working Group is 
formed by merging the isis and ospf WGs and will take on all their existing 
adopted work at the time of chartering.

IS-IS is an IGP specified and standardized by ISO through ISO 10589:2002 and 
additional RFC standards with extensions to support IP that has been deployed 
in the Internet for decades.  For the IS-IS protocol, LSR’s work is focused on 
IP routing, currently based on the agreement in RFC 3563 with ISO/JTC1/SC6. The 
LSR WG will interact with other standards bodies that have responsible for 
standardizing IS-IS.

OSPFv2 [RFC 2328 and extensions], is an IGP that has been deployed in the 
Internet for decades. OSPFv3 [RFC5340 and extensions] provides OSPF for IPv6 
and IPv4 [RFC5838] which can be delivered over IPv6 or IPv4 [RFC 7949].

The LSR Working Group will generally manage its specific work items by 
milestones agreed with the responsible Area Director.

The following topics are expected to be an initial focus:

1) Improving OSPF support for IPv6 and extensions using OSPFv3 LSA 
Extendibility.
2) Extensions needed for Segment Routing and associated architectural changes
3) YANG models for IS-IS, OSPFv2, and OSPFv3 and extensions
4) Extensions for source-destination routing [draft-ietf-rtgwg-dst-src-routing]
5) Potentially, extensions to better support specific network topologies such as
ones commonly used in data centers.

The Link-State Routing (LSR) Working Group will coordinate with other working 
groups, such as RTGWG, SPRING, MPLS, TEAS, V6OPS, and 6MAN, to understand the 
need for extensions and to confirm that the planned work meets the needs.  LSR 
can coordinate with CCAMP and BIER on their extensions to the LSR IGPs as 
useful.  LSR may coordinate with other WGs as needed.

Regards,
Alia
___
Isis-wg mailing list
Isis-wg@ietf.org
https://www.ietf.org/mailman/listinfo/isis-wg

Re: [Isis-wg] Link-State Routing WG charter

[Dolganow, Andrew (Nokia - SG/Singapore)]

+1 to that

From: Isis-wg  on behalf of "Acee Lindem (acee)" 

Date: Friday, January 26, 2018 at 3:18 AM
To: "Les Ginsberg (ginsberg)" , Stewart Bryant 
, Alia Atlas 
Cc: OSPF List , "isis-wg@ietf.org" 
Subject: Re: [Isis-wg] Link-State Routing WG charter

I agree with Les about being selective about LSR non-routing usage.

Thanks,
Acee

From: "Les Ginsberg (ginsberg)" 
Date: Thursday, January 25, 2018 at 1:59 PM
To: Stewart Bryant , Acee Lindem , 
Alia Atlas 
Cc: OSPF WG List , "isis-wg@ietf.org" 
Subject: RE: [Isis-wg] Link-State Routing WG charter

Stewart -

From: Stewart Bryant [mailto:stewart.bry...@gmail.com]
Sent: Thursday, January 25, 2018 4:32 AM
To: Les Ginsberg (ginsberg) ; Acee Lindem (acee) 
; Alia Atlas 
Cc: OSPF List ; isis-wg@ietf.org
Subject: Re: [Isis-wg] Link-State Routing WG charter




Les

I agree wrt L2

Isn't another focus collecting the information to feed into an SDN controller 
via BGP-LS? That is really network layer  state collection rather than routing 
in the traditional sense.



[Les:] Please do not propose such language. This raises the old discussion 
about using the IGPs as a transport for “just about anything”.

We long ago agreed that TE related information was “routing information” – if 
for no other reason than it was grandfathered in. But this does not alter the 
IGP’s focus on routing.

I know we “stretch” the definition with things like MSD and S-BFD 
discriminators, but I see these as carefully considered choices – and ones w 
modest impact.

Institutionalizing the IGPs as an “SDN Distribution Protocol” is not something 
I want in the charter.

   Les



- Stewart

On 24/01/2018 23:09, Les Ginsberg (ginsberg) wrote:
It occurred to me after sending this that perhaps a better statement as regards 
IS-IS would be:

“LSR’s work is focused on IP/IPv6 and Layer 2 routing…”

though admittedly there isn’t much going on as regards Layer2 and IS-IS at the 
moment.

   Les


From: Isis-wg [mailto:isis-wg-boun...@ietf.org] On Behalf Of Les Ginsberg 
(ginsberg)
Sent: Wednesday, January 24, 2018 2:33 PM
To: Stewart Bryant ; 
Acee Lindem (acee) ; Alia Atlas 

Cc: OSPF List ; 
isis-wg@ietf.org
Subject: Re: [Isis-wg] Link-State Routing WG charter

Since a charter only provides a general definition of the work that falls 
within the purview of the WG it requires some adjunct to keep track of the 
current priorities.
That could be the list of milestones (which OSPF has regularly maintained – but 
IS-IS has not) – or it could simply be the list of active WG documents.
I just don’t see that we should expect the charter to express “work in 
progress” now – or in the future.

Alia – do you think the statement about IS-IS:

“LSR’s work is focused on IP routing…”

Could be improved by saying

“LSR’s work is focused on IP/IPv6 routing…”

???

   Les


From: Isis-wg [mailto:isis-wg-boun...@ietf.org] On Behalf Of Stewart Bryant
Sent: Wednesday, January 24, 2018 10:01 AM
To: Acee Lindem (acee) mailto:a...@cisco.com>>; Alia Atlas 
mailto:akat...@gmail.com>>
Cc: OSPF List mailto:o...@ietf.org>>; 
isis-wg@ietf.org
Subject: Re: [Isis-wg] Link-State Routing WG charter


Yes that fixes that.

How about:

s/The following topics are expected to be an initial focus:/ In addition to 
ongoing maintenance, the following topics are expected to be an initial focus:/

I am just concerned that we need not to loose focus on work in progress.

- Stewart

On 24/01/2018 17:54, Acee Lindem (acee) wrote:
How about:

LSR will coordinate with CCAMP and BIER on their extensions to the LSR IGPs as
applicable to LSV protocol operation and scale.

Thanks,
Acee

From: Isis-wg  on 
behalf of Alia Atlas 
Date: Wednesday, January 24, 2018 at 12:42 PM
To: Stewart Bryant 
Cc: OSPF WG List , 
"isis-wg@ietf.org" 

Subject: Re: [Isis-wg] Link-State Routing WG charter

Hi Stewart,

Thanks for the quick feedback.  Feel free to provide suggestions for text 
changes if you have them.
You've certainly written enough charters :-)

Regards,
Alia

On Wed, Jan 24, 2018 at 12:32 PM, Stewart Bryant 
mailto:stewart.bry...@gmail.com>> wrote:

Alia,
I think that this merger is long overdue, and hopefully it will help new 
features to be written in an aligned way.

I think the remit to perform general maintenance should slightly clarified 
since the way the charter is written they look like they are at a lower 
priority than the enumerated list.

I would have thought that "LSR can coordinate with CCAMP and BIER on their 
extensions " should have been more directive.

- Stewart

On 24/01/2018 17:18, Alia Atlas wrote:
Here is the proposed charter for the LSR working group
that will be created from the SPF and ISIS working groups.