Re: [Lsr] Handling multiple Extended IS Reachability TLVs for a link

[Les Ginsberg (ginsberg)]

Ketan –

You have the wrong idea about this draft.

The draft is NOT introducing multi-part-TLV support to IS-IS – nor is it 
altering the mechanisms available to be used when sending multi-part-TLVs.
The protocol has always had the capability to support this and there are 
multiple known implementations already deployed which have implemented 
multi-part-TLV support and they are not subject to whatever restrictions you 
(or anyone) might think should be used.
It is too late (and unnecessary) to introduce such ideas.

What this draft is doing is describing the correct procedures to be used when 
advertising multi-part-TLVs – but it is not limiting any of the existing valid 
options which may already be in use.

As far as your proposal (which for me did not require clarification – I already 
understood the intended scope), I would not choose to do things that way even 
if we had the flexibility to do so.

As an implementor, I would not want to encode the link identifiers one way if I 
had only one TLV but another if I had more than one. That adds additional 
complexity to the implementation.

And your idea that link ids only could be used in “the non-first-part-TLVs” has 
fatal flaws.
For one thing, you can’t tell which of the TLVs is the “first one”.  It could 
be that you initially sent a TLV in LSP #10. Later, when you needed additional 
space you created a second TLV but there was no room in LSP #10 – but there was 
room in LSP #5.
Point is, in IS-IS order of advertisement does not matter.

In order to be able to match the two TLVs on reception, it is necessary to have 
at least one set of identifiers in common in the TLVs. If one of the TLVs only 
has link ids, then all the TLVs have to have link ids.
Which forces all implementations to send link ids all the time. And not all 
implementations today choose to send link ids all the time – no reason to force 
them to do so.
And I could go on…

Hopefully I have made my point.

Les



From: Ketan Talaulikar 
Sent: Thursday, June 30, 2022 8:57 PM
To: Les Ginsberg (ginsberg) 
Cc: Huzhibo ; Tony Li ; 
draft-pkaneria-lsr-multi-...@ietf.org; lsr 
Subject: Re: [Lsr] Handling multiple Extended IS Reachability TLVs for a link

Hi Les,

Please check inline below for some clarifications with KT2.


On Thu, Jun 30, 2022 at 10:57 PM Les Ginsberg (ginsberg) 
mailto:ginsb...@cisco.com>> wrote:
Ketan –

Inline.

From: Ketan Talaulikar mailto:ketant.i...@gmail.com>>
Sent: Thursday, June 30, 2022 10:12 AM
To: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>
Cc: Huzhibo mailto:huzh...@huawei.com>>; Tony Li 
mailto:tony...@tony.li>>; 
draft-pkaneria-lsr-multi-...@ietf.org;
 lsr mailto:lsr@ietf.org>>
Subject: Re: [Lsr] Handling multiple Extended IS Reachability TLVs for a link

Hi Les,

Please check inline below.

On Thu, Jun 30, 2022 at 10:13 PM Les Ginsberg (ginsberg) 
mailto:ginsb...@cisco.com>> wrote:
Ketan/Zhibo –

It is worth reemphasizing that there are no protocol extensions used or 
required for supporting multi-part-TLVs.

KT> I was referring to protocol behavior and requirements related to this 
handling. In my view, that is an "extension" of the protocol behavior - but we 
can agree to disagree on this point? :-) I see that the draft is 
standards-track and I am good with it.

This isn’t speculation – this is based on actual implementation.

As to keys, the draft already discusses the key for prefix advertisements. As 
the key in that case is the fixed portion of the TLV advertisement, any 
omission would make the TLV syntactically invalid.

For the link case, what is required is at least one of the link identifiers 
(IPv4 endpoint addresses, IPv6 endpoint addresses, and/or Link IDs).

KT> Agree and this is something worth discussing. My suggestion would be that 
Local-Remote-ID is recommended as the only "key" that is required to be 
repeated across TLV instances to achieve the most compactness. Remote ID could 
be 0 when it cannot be determined. IPv6 addresses would take up more space and 
also, there can be multiple instances of the IP "endpoint" addresses so using 
them as "key" might make implementations more complex.

[LES:] No – I absolutely don’t want to do that. You would be creating 
interoperability problems by this proposal – and unnecessarily so.
Some implementations today send Link IDs all the time. Some only send them when 
an interface is unnumbered. It should not matter.
And note that this applies to interoperability even without multi-part-TLVs 
i.e., you would be defining a restriction that does not apply today.

KT2> I am not suggesting that the link addresses are not considered "link 
identifiers". So there is no cause for any issues for single-part-TLVs. My 
point was that when we have multi-part-TLVs, only the local-remote-IDs be the 
only sub-TLV that need repetition in all the non-first-part-TLVs. The link 
addresses are still carried as link identifiers when available (i.e. when not 

Re: [Lsr] Handling multiple Extended IS Reachability TLVs for a link

[Ketan Talaulikar]

Hi Les,

Please check inline below for some clarifications with KT2.


On Thu, Jun 30, 2022 at 10:57 PM Les Ginsberg (ginsberg) 
wrote:

> Ketan –
>
>
>
> Inline.
>
>
>
> *From:* Ketan Talaulikar 
> *Sent:* Thursday, June 30, 2022 10:12 AM
> *To:* Les Ginsberg (ginsberg) 
> *Cc:* Huzhibo ; Tony Li ;
> draft-pkaneria-lsr-multi-...@ietf.org; lsr 
> *Subject:* Re: [Lsr] Handling multiple Extended IS Reachability TLVs for
> a link
>
>
>
> Hi Les,
>
>
>
> Please check inline below.
>
>
>
> On Thu, Jun 30, 2022 at 10:13 PM Les Ginsberg (ginsberg) <
> ginsb...@cisco.com> wrote:
>
> Ketan/Zhibo –
>
>
>
> It is worth reemphasizing that there are no protocol extensions used or
> required for supporting multi-part-TLVs.
>
>
>
> KT> I was referring to protocol behavior and requirements related to this
> handling. In my view, that is an "extension" of the protocol behavior - but
> we can agree to disagree on this point? :-) I see that the draft is
> standards-track and I am good with it.
>
>
>
> This isn’t speculation – this is based on actual implementation.
>
>
>
> As to keys, the draft already discusses the key for prefix advertisements.
> As the key in that case is the fixed portion of the TLV advertisement, any
> omission would make the TLV syntactically invalid.
>
>
>
> For the link case, what is required is at least one of the link
> identifiers (IPv4 endpoint addresses, IPv6 endpoint addresses, and/or Link
> IDs).
>
>
>
> KT> Agree and this is something worth discussing. My suggestion would be
> that Local-Remote-ID is recommended as the only "key" that is required to
> be repeated across TLV instances to achieve the most compactness. Remote ID
> could be 0 when it cannot be determined. IPv6 addresses would take up more
> space and also, there can be multiple instances of the IP "endpoint"
> addresses so using them as "key" might make implementations more complex.
>
>
>
> *[LES:] No – I absolutely don’t want to do that. You would be creating
> interoperability problems by this proposal – and unnecessarily so.*
>
> *Some implementations today send Link IDs all the time. Some only send
> them when an interface is unnumbered. It should not matter.*
>
> *And note that this applies to interoperability even without
> multi-part-TLVs i.e., you would be defining a restriction that does not
> apply today.*
>

KT2> I am not suggesting that the link addresses are not considered "link
identifiers". So there is no cause for any issues for single-part-TLVs. My
point was that when we have multi-part-TLVs, only the local-remote-IDs be
the only sub-TLV that need repetition in all the non-first-part-TLVs. The
link addresses are still carried as link identifiers when available (i.e.
when not unnumbered) in the first part.

Just want to make sure that my proposal is specific to multi-part.

Thanks,
Ketan


>
>
> *   Les*
>
> These sub-TLVs were defined many years ago and are required for support of
> all forms of TE as well as other technologies (e.g., Segment Routing). I
> would not object to some discussion of this case in the draft, but the idea
> that this is in some way “new” or might not be understood by implementors
> is not credible to me. If you aren’t sending these identifiers already then
> you would never be able to support TE, Segment Routing, etc.
>
>
>
> KT> I am glad to hear that these points will be discussed.
>
>
>
> Thanks,
>
> Ketan
>
>
>
>
>
> It is also worth noting that there are existing RFCs that have already
> explicitly specified the use of multi-part-TLVs. These include:
>
>
>
> RFC 5307 SRLG TLV
>
> RFC 7981 Router Capability TLV
>
>
>
> Les
>
>
>
> *From:* Huzhibo 
> *Sent:* Thursday, June 30, 2022 12:43 AM
> *To:* Ketan Talaulikar ; Les Ginsberg (ginsberg) <
> ginsb...@cisco.com>
> *Cc:* Tony Li ; draft-pkaneria-lsr-multi-...@ietf.org;
> lsr 
> *Subject:* RE: [Lsr] Handling multiple Extended IS Reachability TLVs for
> a link
>
>
>
> Hi Everyone:
>
>
>
> I think it is necessary to specify the key of the TLV and the information
> that needs to be carried repeatedly in this document. I am not sure that
> everyone has the same understanding of the key. If different vendors have
> different understandings of the key, there may be interoperability problems.
>
>
>
> Thanks
>
>
>
> Zhibo
>
>
>
> *From:* Lsr [mailto:lsr-boun...@ietf.org ] *On
> Behalf Of *Ketan Talaulikar
> *Sent:* Thursday, June 30, 2022 11:15 AM
> *To:* Les Ginsberg (ginsberg) 
> *Cc:* Tony Li ; draft-pkaneria-lsr-multi-...@ietf.org;
> lsr 
> *Subject:* Re: [Lsr] Handling multiple Extended IS Reachability TLVs for
> a link
>
>
>
> Hi Les,
>
>
>
> Please check inline below.
>
>
>
> On Wed, Jun 29, 2022 at 11:05 PM Les Ginsberg (ginsberg) <
> ginsb...@cisco.com> wrote:
>
> Ketan –
>
>
>
> To add to what Tony has said…one thing which we did not want this draft
> to become was for it to be the place where a definition of the “key” for
> every TLV was defined.
>
>
>
> KT> I agree.
>
>
>
> Perhaps in the text you quote “MUST” should not be 

Re: [Lsr] [Idr] draft-head-idr-bgp-ls-isis-fr-01 - WG adoption call (6/6 to 6/20)

[Robert Raszuk]

Hello,

I have a question ... likely to the WG chairs.

Why
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-isis-flood-reflection-07
does not have a YANG section ? Is there a separate document for it just
like we see a separate document for BGP-LS encoding ?

Isn't the YANG section a requirement for all protocol extension
documents before they are sent for publications these days ?

The reason I am asking this is in fact in light of the other discussions we
have on IDR list where at least one mode of link state state advertisement
can be done using YANG encoding. Is YANG section optional in LSR WG
documents which define new protocol extensions and new functionality ? If
an implementation uses YANG to push LSDB how the new TLVs defined in the
draft are going to be shared across ?

Many thx,
Robert


On Wed, Jun 29, 2022 at 10:56 PM Susan Hares  wrote:

> Greetings:
>
>
>
> I want to thank all the people who contributed to this WG adoption call.
>
>
>
> There are four points I pull from the adoption call:
>
>
>
> 1. IDR participants desire to discuss other potential ways to pass data
> currently past in IDR
>
>
>
> I will start a thread noted as “BGP-LS” alternative.   This thread has 2
> subjects:
>
> 1) clear problem statements on BGP-LS
>
> 2) Discussion of alternatives (e.g. Droid (draft-li-lsr-droid-00.txt)
>
>
>
> If there is enough on list discussion, IDR may hold an interim on the
> topic.
>
>
>
> 2.  Operators wish to deploy this draft
>
>
>
> I have confirmation on requests for deploying this draft.
>
> Like some other BGP features, it may not be widely deployed.
>
>
>
> 3. The WG wishes to add these features to this experimental draft.
>
>
>
> draft-ietf-idr-bgp-ls-isis-flood-reflection-00.txt
>
>
>
> Based on the call, this draft should include the changes promised on the
> call.
>
> The authors should resubmit the draft with this name.
>
>
>
> 4. The IDR + LSR chairs should review the agreements relating to
>
> BGP-LS TLVs at IETF-114 in their WG.
>
>
>
> The IDR chairs will request a time at IDR + LSR for this topic.
>
> Let  me know if a short video be better than slides.
>
> If so, we’ll post the video on YouTube before IETF and
>
> Take questions at LSR or IDR.
>
>
>
> Cheers, Sue Hares
>
>
>
> *From:* Lsr  *On Behalf Of * Susan Hares
> *Sent:* Friday, June 24, 2022 9:29 AM
> *To:* Tony Przygienda ; Ketan Talaulikar <
> ketant.i...@gmail.com>
> *Cc:* Jordan Head ; i...@ietf.org; lsr 
> *Subject:* Re: [Lsr] [Idr] draft-head-idr-bgp-ls-isis-fr-01 - WG adoption
> call (6/6 to 6/20)
>
>
>
>
>
> Tony P, Ketan and IDR WG:
>
>
>
> Thank you for input on this draft.
>
> I am closing the WG adoption call for this draft.
>
> The IDR Chairs will discuss the results of this consensus call, and
>
> Announce the results by July 8th.
>
>
>
> Cheers,
>
>
>
> Sue Hares
>
>
>
> *From:* Tony Przygienda 
> *Sent:* Wednesday, June 22, 2022 12:11 PM
> *To:* Ketan Talaulikar 
> *Cc:* Jordan Head ; Susan Hares ;
> i...@ietf.org; lsr 
> *Subject:* Re: [Idr] draft-head-idr-bgp-ls-isis-fr-01 - WG adoption call
> (6/6 to 6/20)
>
>
>
>
>
> hey Ketan, since as you know ;-) BGP-LS is not really IGP 1:1 translation
> we try to put into BGP-LS here only the stuff that is strictly needed for
> topology discovery and understanding for advanced computation and nothing
> else. And hence, since the 1:1 TLV correspondence is nowhere to be seen by
> now if you look at ospf/isis encoding and what BGP-LS formats are today
> your requirements are interesting but I'm not sure where they came from.
>
>
>
> The flag indicates already whether something is client or reflector on an
> adjacency. cluster ID is there as well to differentiate between different
> clusters. L2 C/FR adjacencies will show up as well. good enough to
> understand topology and compute AFAIS.  All this is achievable by putting
> this element on the link TLV (the draft should explain it better, it just
> grabs codepoints in node/link/prefix & e'thing else ;-). Yes, we could
> annotate just the node assuming strict adherence to the IGP draft today but
> putting the element on the link descriptor follows the IGP spec itself and
> will allow to break the RFC if necessary later also in BGP-LS (by e.g.
> allowing a node to be client of two different clusters or even a node being
> reflector for 2 different clusters. Observe that this will not work in case
> of auto-discoery since that's on node caps ;-) But those are sutble
> discussions that need to be documented into the BGP-LS draft as procedures
> once adopted. Those discussions are natural and necessary since BGP-LS is
> NOT IGP  database but a distorted, simplified view for topology discovery.
> Or at least that's how it's used in reality based on the shortcomings of
> its design ;-)
>
>
>
> As I explained, unless L1 adjacencies are being formed IMO they don't
> belong into BGP-LS FR information, otherwise will show up in BGP-LS
> naturally. Neither does IMO auto-discovery of FR.
>
>
>
> As to mismatch of e.g. 

Re: [Lsr] Handling multiple Extended IS Reachability TLVs for a link

[Les Ginsberg (ginsberg)]

Ketan –

Inline.

From: Ketan Talaulikar 
Sent: Thursday, June 30, 2022 10:12 AM
To: Les Ginsberg (ginsberg) 
Cc: Huzhibo ; Tony Li ; 
draft-pkaneria-lsr-multi-...@ietf.org; lsr 
Subject: Re: [Lsr] Handling multiple Extended IS Reachability TLVs for a link

Hi Les,

Please check inline below.

On Thu, Jun 30, 2022 at 10:13 PM Les Ginsberg (ginsberg) 
mailto:ginsb...@cisco.com>> wrote:
Ketan/Zhibo –

It is worth reemphasizing that there are no protocol extensions used or 
required for supporting multi-part-TLVs.

KT> I was referring to protocol behavior and requirements related to this 
handling. In my view, that is an "extension" of the protocol behavior - but we 
can agree to disagree on this point? :-) I see that the draft is 
standards-track and I am good with it.

This isn’t speculation – this is based on actual implementation.

As to keys, the draft already discusses the key for prefix advertisements. As 
the key in that case is the fixed portion of the TLV advertisement, any 
omission would make the TLV syntactically invalid.

For the link case, what is required is at least one of the link identifiers 
(IPv4 endpoint addresses, IPv6 endpoint addresses, and/or Link IDs).

KT> Agree and this is something worth discussing. My suggestion would be that 
Local-Remote-ID is recommended as the only "key" that is required to be 
repeated across TLV instances to achieve the most compactness. Remote ID could 
be 0 when it cannot be determined. IPv6 addresses would take up more space and 
also, there can be multiple instances of the IP "endpoint" addresses so using 
them as "key" might make implementations more complex.

[LES:] No – I absolutely don’t want to do that. You would be creating 
interoperability problems by this proposal – and unnecessarily so.
Some implementations today send Link IDs all the time. Some only send them when 
an interface is unnumbered. It should not matter.
And note that this applies to interoperability even without multi-part-TLVs 
i.e., you would be defining a restriction that does not apply today.

   Les
These sub-TLVs were defined many years ago and are required for support of all 
forms of TE as well as other technologies (e.g., Segment Routing). I would not 
object to some discussion of this case in the draft, but the idea that this is 
in some way “new” or might not be understood by implementors is not credible to 
me. If you aren’t sending these identifiers already then you would never be 
able to support TE, Segment Routing, etc.

KT> I am glad to hear that these points will be discussed.

Thanks,
Ketan


It is also worth noting that there are existing RFCs that have already 
explicitly specified the use of multi-part-TLVs. These include:

RFC 5307 SRLG TLV
RFC 7981 Router Capability TLV

Les

From: Huzhibo mailto:huzh...@huawei.com>>
Sent: Thursday, June 30, 2022 12:43 AM
To: Ketan Talaulikar mailto:ketant.i...@gmail.com>>; Les 
Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>
Cc: Tony Li mailto:tony...@tony.li>>; 
draft-pkaneria-lsr-multi-...@ietf.org;
 lsr mailto:lsr@ietf.org>>
Subject: RE: [Lsr] Handling multiple Extended IS Reachability TLVs for a link

Hi Everyone:

I think it is necessary to specify the key of the TLV and the information that 
needs to be carried repeatedly in this document. I am not sure that everyone 
has the same understanding of the key. If different vendors have different 
understandings of the key, there may be interoperability problems.

Thanks

Zhibo

From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Ketan Talaulikar
Sent: Thursday, June 30, 2022 11:15 AM
To: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>
Cc: Tony Li mailto:tony...@tony.li>>; 
draft-pkaneria-lsr-multi-...@ietf.org;
 lsr mailto:lsr@ietf.org>>
Subject: Re: [Lsr] Handling multiple Extended IS Reachability TLVs for a link

Hi Les,

Please check inline below.

On Wed, Jun 29, 2022 at 11:05 PM Les Ginsberg (ginsberg) 
mailto:ginsb...@cisco.com>> wrote:
Ketan –

To add to what Tony has said…one thing which we did not want this draft to 
become was for it to be the place where a definition of the “key” for every TLV 
was defined.

KT> I agree.

Perhaps in the text you quote “MUST” should not be capitalized as we are simply 
describing the generic logic required.

KT> I think it would be better for the first part of the draft to just describe 
the general rules/logic for handling these cases. This part should stand on its 
own. Whether it needs to be normative or not, can be discussed later. IMHO, if 
normative language is better and the text can be worked out as the document 
progresses.


It is also worth pointing out that this draft is not defining new behavior nor 
is it extending the protocol in any way.

KT> I don't fully agree with that ...

The use of multiple TLVs for a given object is already implemented and deployed 
by multiple vendors and does not require any protocol 

Re: [Lsr] Handling multiple Extended IS Reachability TLVs for a link

[Ketan Talaulikar]

Hi Les,

Please check inline below.

On Thu, Jun 30, 2022 at 10:13 PM Les Ginsberg (ginsberg) 
wrote:

> Ketan/Zhibo –
>
>
>
> It is worth reemphasizing that there are no protocol extensions used or
> required for supporting multi-part-TLVs.
>

KT> I was referring to protocol behavior and requirements related to this
handling. In my view, that is an "extension" of the protocol behavior - but
we can agree to disagree on this point? :-) I see that the draft is
standards-track and I am good with it.


> This isn’t speculation – this is based on actual implementation.
>
>
>
> As to keys, the draft already discusses the key for prefix advertisements.
> As the key in that case is the fixed portion of the TLV advertisement, any
> omission would make the TLV syntactically invalid.
>
>
>
> For the link case, what is required is at least one of the link
> identifiers (IPv4 endpoint addresses, IPv6 endpoint addresses, and/or Link
> IDs).
>

KT> Agree and this is something worth discussing. My suggestion would be
that Local-Remote-ID is recommended as the only "key" that is required to
be repeated across TLV instances to achieve the most compactness. Remote ID
could be 0 when it cannot be determined. IPv6 addresses would take up more
space and also, there can be multiple instances of the IP "endpoint"
addresses so using them as "key" might make implementations more complex.


> These sub-TLVs were defined many years ago and are required for support of
> all forms of TE as well as other technologies (e.g., Segment Routing). I
> would not object to some discussion of this case in the draft, but the idea
> that this is in some way “new” or might not be understood by implementors
> is not credible to me. If you aren’t sending these identifiers already then
> you would never be able to support TE, Segment Routing, etc.
>

KT> I am glad to hear that these points will be discussed.

Thanks,
Ketan


>
>
> It is also worth noting that there are existing RFCs that have already
> explicitly specified the use of multi-part-TLVs. These include:
>
>
>
> RFC 5307 SRLG TLV
>
> RFC 7981 Router Capability TLV
>
>
>
> Les
>
>
>
> *From:* Huzhibo 
> *Sent:* Thursday, June 30, 2022 12:43 AM
> *To:* Ketan Talaulikar ; Les Ginsberg (ginsberg) <
> ginsb...@cisco.com>
> *Cc:* Tony Li ; draft-pkaneria-lsr-multi-...@ietf.org;
> lsr 
> *Subject:* RE: [Lsr] Handling multiple Extended IS Reachability TLVs for
> a link
>
>
>
> Hi Everyone:
>
>
>
> I think it is necessary to specify the key of the TLV and the information
> that needs to be carried repeatedly in this document. I am not sure that
> everyone has the same understanding of the key. If different vendors have
> different understandings of the key, there may be interoperability problems.
>
>
>
> Thanks
>
>
>
> Zhibo
>
>
>
> *From:* Lsr [mailto:lsr-boun...@ietf.org ] *On
> Behalf Of *Ketan Talaulikar
> *Sent:* Thursday, June 30, 2022 11:15 AM
> *To:* Les Ginsberg (ginsberg) 
> *Cc:* Tony Li ; draft-pkaneria-lsr-multi-...@ietf.org;
> lsr 
> *Subject:* Re: [Lsr] Handling multiple Extended IS Reachability TLVs for
> a link
>
>
>
> Hi Les,
>
>
>
> Please check inline below.
>
>
>
> On Wed, Jun 29, 2022 at 11:05 PM Les Ginsberg (ginsberg) <
> ginsb...@cisco.com> wrote:
>
> Ketan –
>
>
>
> To add to what Tony has said…one thing which we did not want this draft
> to become was for it to be the place where a definition of the “key” for
> every TLV was defined.
>
>
>
> KT> I agree.
>
>
>
> Perhaps in the text you quote “MUST” should not be capitalized as we are
> simply describing the generic logic required.
>
>
>
> KT> I think it would be better for the first part of the draft to just
> describe the general rules/logic for handling these cases. This part should
> stand on its own. Whether it needs to be normative or not, can be discussed
> later. IMHO, if normative language is better and the text can be worked out
> as the document progresses.
>
>
>
>
>
> It is also worth pointing out that this draft is not defining new behavior
> nor is it extending the protocol in any way.
>
>
>
> KT> I don't fully agree with that ...
>
>
>
> The use of multiple TLVs for a given object is already implemented and
> deployed by multiple vendors and does not require any protocol extensions.
>
>
>
> KT> I agree that this problem has been around for some time now. I agree
> that there are implementations that have "worked out a solution" and that
> they are also deployed. There aren't that many ways to tackle this after
> all ;-) ... that said, this handling is not yet specified in an RFC or ISO
> document, right? If not then, IMHO, this is an extension of the protocol
> behavior.
>
>
>
> Given the increasing need for using multiple TLVs, it seemed prudent to
> document the generic behavior – which is the motivation for this draft.
>
>
>
> KT> Agree. Also agree at a high level with the proposal. Again, there are
> not too many different ways to go about this :-)
>
>
>
> But there is no intent to discuss all 

Re: [Lsr] Request 5-10 minutes

[Susan Hares]

Acee:

Agreed.  All IDR and LSR chairs must agree to
the description of the process and presentation.

Or we’ll revert to the old procedure (BGP-LS TLVS
specified in IDR draft and LSR drafts).

Sue

PS – Just trying to get a jump on IETF-114 work.

From: Lsr  On Behalf Of Acee Lindem (acee)
Sent: Thursday, June 30, 2022 12:54 PM
To: Susan Hares ; lsr@ietf.org
Subject: Re: [Lsr] Request 5-10 minutes

We will reserve time on the agenda for this since it is important. However, I’d 
hope we (the LSR chairs) would be involved as well. Thanks, Acee  ‌  ‌  ‌  ‌  ‌ 
 ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌
External 
(acee=40cisco@dmarc.ietf.org)
  Report This 
Email
  FAQ  GoDaddy Advanced Email Security, 
Powered by INKY

We will reserve  time on the agenda for this since it is important. However, 
I’d hope we (the LSR chairs) would be involved as well.
Thanks,
Acee

From: Susan Hares mailto:sha...@ndzh.com>>
Date: Thursday, June 30, 2022 at 12:51 PM
To: Acee Lindem mailto:a...@cisco.com>>, 
"lsr@ietf.org" mailto:lsr@ietf.org>>
Subject: RE: [Lsr] Request 5-10 minutes

Acee:

A presentation on the rules for included BGP-LS TLVs in
LSR drafts will not occur in IDR or LSR unless you and Chris both agree
with the slides and the content of the slides.

If you do not have time in LSR – we will provide time
In IDR WG for Q on the topic.

Based on the feedback on the adoption call for
draft-head-idr-bgp-ls-isis-fr-00.txt
(now: draft-ietf-idr-bgp-ls-isis-flood-reduction-00.txt),
it appears the IDR chairs were unclear about the rules
for including BGP-LS TLVs in LSR specifications.

It seems wise to clarify these rules for BGP-LS TLVs
for LSR and IDR.

If we do not have consensus within the LSR and IDR chairs
on the rules for BGP-LS TLVs In LSR drafts by IETF-114,
we will go back to the previous mechanism of
requiring drafts in LSR and IDR.

Cheers, Sue

PS – I was going to work on the slides and a YouTube
Video for the slides this weekend.

From: Acee Lindem (acee) mailto:a...@cisco.com>>
Sent: Thursday, June 30, 2022 12:37 PM
To: Susan Hares mailto:sha...@ndzh.com>>; 
lsr@ietf.org
Subject: Re: [Lsr] Request 5-10 minutes


Note that to the best of my knowledge, the LSR chairs have not agreed to these 
slides so I must assume the agreement is amongst the IDR chairs?
Acee

From: Lsr mailto:lsr-boun...@ietf.org>> on behalf of 
Susan Hares mailto:sha...@ndzh.com>>
Date: Thursday, June 30, 2022 at 12:24 PM
To: "lsr@ietf.org" mailto:lsr@ietf.org>>
Subject: [Lsr] Request 5-10 minutes

The IDR chairs wish to request 5-7 minute time slot to present
IDR chair agreement with LSR chairs on BGP-LS TLVs in
LSR WG drafts.

Cheers, Sue Hares




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

Re: [Lsr] Request 5-10 minutes

[Acee Lindem (acee)]

We will reserve  time on the agenda for this since it is important. However, 
I’d hope we (the LSR chairs) would be involved as well.
Thanks,
Acee

From: Susan Hares 
Date: Thursday, June 30, 2022 at 12:51 PM
To: Acee Lindem , "lsr@ietf.org" 
Subject: RE: [Lsr] Request 5-10 minutes

Acee:

A presentation on the rules for included BGP-LS TLVs in
LSR drafts will not occur in IDR or LSR unless you and Chris both agree
with the slides and the content of the slides.

If you do not have time in LSR – we will provide time
In IDR WG for Q on the topic.

Based on the feedback on the adoption call for
draft-head-idr-bgp-ls-isis-fr-00.txt
(now: draft-ietf-idr-bgp-ls-isis-flood-reduction-00.txt),
it appears the IDR chairs were unclear about the rules
for including BGP-LS TLVs in LSR specifications.

It seems wise to clarify these rules for BGP-LS TLVs
for LSR and IDR.

If we do not have consensus within the LSR and IDR chairs
on the rules for BGP-LS TLVs In LSR drafts by IETF-114,
we will go back to the previous mechanism of
requiring drafts in LSR and IDR.

Cheers, Sue

PS – I was going to work on the slides and a YouTube
Video for the slides this weekend.

From: Acee Lindem (acee) 
Sent: Thursday, June 30, 2022 12:37 PM
To: Susan Hares ; lsr@ietf.org
Subject: Re: [Lsr] Request 5-10 minutes


Note that to the best of my knowledge, the LSR chairs have not agreed to these 
slides so I must assume the agreement is amongst the IDR chairs?
Acee

From: Lsr mailto:lsr-boun...@ietf.org>> on behalf of 
Susan Hares mailto:sha...@ndzh.com>>
Date: Thursday, June 30, 2022 at 12:24 PM
To: "lsr@ietf.org" mailto:lsr@ietf.org>>
Subject: [Lsr] Request 5-10 minutes

The IDR chairs wish to request 5-7 minute time slot to present
IDR chair agreement with LSR chairs on BGP-LS TLVs in
LSR WG drafts.

Cheers, Sue Hares




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

Re: [Lsr] Request 5-10 minutes

[Susan Hares]

Acee:

A presentation on the rules for included BGP-LS TLVs in
LSR drafts will not occur in IDR or LSR unless you and Chris both agree
with the slides and the content of the slides.

If you do not have time in LSR – we will provide time
In IDR WG for Q on the topic.

Based on the feedback on the adoption call for
draft-head-idr-bgp-ls-isis-fr-00.txt
(now: draft-ietf-idr-bgp-ls-isis-flood-reduction-00.txt),
it appears the IDR chairs were unclear about the rules
for including BGP-LS TLVs in LSR specifications.

It seems wise to clarify these rules for BGP-LS TLVs
for LSR and IDR.

If we do not have consensus within the LSR and IDR chairs
on the rules for BGP-LS TLVs In LSR drafts by IETF-114,
we will go back to the previous mechanism of
requiring drafts in LSR and IDR.

Cheers, Sue

PS – I was going to work on the slides and a YouTube
Video for the slides this weekend.

From: Acee Lindem (acee) 
Sent: Thursday, June 30, 2022 12:37 PM
To: Susan Hares ; lsr@ietf.org
Subject: Re: [Lsr] Request 5-10 minutes

Note that to the best of my knowledge, the LSR chairs have not agreed to these 
slides so I must assume the agreement is amongst the IDR chairs? Acee  ‌  ‌  ‌  
‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌
External (a...@cisco.com)
  Report This 
Email
  FAQ  GoDaddy Advanced Email Security, 
Powered by INKY

Note that to the best of my knowledge, the LSR chairs have not agreed to these 
slides so I must assume the agreement is amongst the IDR chairs?
Acee

From: Lsr mailto:lsr-boun...@ietf.org>> on behalf of 
Susan Hares mailto:sha...@ndzh.com>>
Date: Thursday, June 30, 2022 at 12:24 PM
To: "lsr@ietf.org" mailto:lsr@ietf.org>>
Subject: [Lsr] Request 5-10 minutes

The IDR chairs wish to request 5-7 minute time slot to present
IDR chair agreement with LSR chairs on BGP-LS TLVs in
LSR WG drafts.

Cheers, Sue Hares




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

Re: [Lsr] Handling multiple Extended IS Reachability TLVs for a link

[Les Ginsberg (ginsberg)]

Ketan/Zhibo –

It is worth reemphasizing that there are no protocol extensions used or 
required for supporting multi-part-TLVs.
This isn’t speculation – this is based on actual implementation.

As to keys, the draft already discusses the key for prefix advertisements. As 
the key in that case is the fixed portion of the TLV advertisement, any 
omission would make the TLV syntactically invalid.

For the link case, what is required is at least one of the link identifiers 
(IPv4 endpoint addresses, IPv6 endpoint addresses, and/or Link IDs). These 
sub-TLVs were defined many years ago and are required for support of all forms 
of TE as well as other technologies (e.g., Segment Routing). I would not object 
to some discussion of this case in the draft, but the idea that this is in some 
way “new” or might not be understood by implementors is not credible to me. If 
you aren’t sending these identifiers already then you would never be able to 
support TE, Segment Routing, etc.

It is also worth noting that there are existing RFCs that have already 
explicitly specified the use of multi-part-TLVs. These include:

RFC 5307 SRLG TLV
RFC 7981 Router Capability TLV

Les

From: Huzhibo 
Sent: Thursday, June 30, 2022 12:43 AM
To: Ketan Talaulikar ; Les Ginsberg (ginsberg) 

Cc: Tony Li ; draft-pkaneria-lsr-multi-...@ietf.org; lsr 

Subject: RE: [Lsr] Handling multiple Extended IS Reachability TLVs for a link

Hi Everyone:

I think it is necessary to specify the key of the TLV and the information that 
needs to be carried repeatedly in this document. I am not sure that everyone 
has the same understanding of the key. If different vendors have different 
understandings of the key, there may be interoperability problems.

Thanks

Zhibo

From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Ketan Talaulikar
Sent: Thursday, June 30, 2022 11:15 AM
To: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>
Cc: Tony Li mailto:tony...@tony.li>>; 
draft-pkaneria-lsr-multi-...@ietf.org;
 lsr mailto:lsr@ietf.org>>
Subject: Re: [Lsr] Handling multiple Extended IS Reachability TLVs for a link

Hi Les,

Please check inline below.

On Wed, Jun 29, 2022 at 11:05 PM Les Ginsberg (ginsberg) 
mailto:ginsb...@cisco.com>> wrote:
Ketan –

To add to what Tony has said…one thing which we did not want this draft to 
become was for it to be the place where a definition of the “key” for every TLV 
was defined.

KT> I agree.

Perhaps in the text you quote “MUST” should not be capitalized as we are simply 
describing the generic logic required.

KT> I think it would be better for the first part of the draft to just describe 
the general rules/logic for handling these cases. This part should stand on its 
own. Whether it needs to be normative or not, can be discussed later. IMHO, if 
normative language is better and the text can be worked out as the document 
progresses.


It is also worth pointing out that this draft is not defining new behavior nor 
is it extending the protocol in any way.

KT> I don't fully agree with that ...

The use of multiple TLVs for a given object is already implemented and deployed 
by multiple vendors and does not require any protocol extensions.

KT> I agree that this problem has been around for some time now. I agree that 
there are implementations that have "worked out a solution" and that they are 
also deployed. There aren't that many ways to tackle this after all ;-) ... 
that said, this handling is not yet specified in an RFC or ISO document, right? 
If not then, IMHO, this is an extension of the protocol behavior.

Given the increasing need for using multiple TLVs, it seemed prudent to 
document the generic behavior – which is the motivation for this draft.

KT> Agree. Also agree at a high level with the proposal. Again, there are not 
too many different ways to go about this :-)

But there is no intent to discuss all possible TLVs to which this behavior 
might apply.

KT> Agree

If you expect that then I think we are not in sync.

It has been discussed that the most common cases where multiple TLVs are likely 
to be required are the Prefix Reachability TLVs and the IS Neighbor TLVs. As 
such, it might not be a bad idea to discuss these two cases (the draft already 
discusses Prefix Reachability).

KT> For most TLVs/sub-TLVs, I believe the "keys" are part of the fixed form and 
hence the problem (unspecified keys) that I mentioned in my first email on this 
thread does not arise. There are though, some TLVs, where the keys remain 
unspecified and I strongly believe that (at least the most important of those?) 
need to be tackled in this document for it to help implementors.

Thanks,
Ketan


   Les

From: Ketan Talaulikar mailto:ketant.i...@gmail.com>>
Sent: Wednesday, June 29, 2022 9:33 AM
To: Tony Li mailto:tony...@tony.li>>
Cc: 
draft-pkaneria-lsr-multi-...@ietf.org;
 lsr mailto:lsr@ietf.org>>
Subject: Re: Handling 

Re: [Lsr] Request 5-10 minutes

[Acee Lindem (acee)]

Note that to the best of my knowledge, the LSR chairs have not agreed to these 
slides so I must assume the agreement is amongst the IDR chairs?

Acee

From: Lsr  on behalf of Susan Hares 
Date: Thursday, June 30, 2022 at 12:24 PM
To: "lsr@ietf.org" 
Subject: [Lsr] Request 5-10 minutes

The IDR chairs wish to request 5-7 minute time slot to present
IDR chair agreement with LSR chairs on BGP-LS TLVs in
LSR WG drafts.

Cheers, Sue Hares




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

[Lsr] Request 5-10 minutes

[Susan Hares]

The IDR chairs wish to request 5-7 minute time slot to present
IDR chair agreement with LSR chairs on BGP-LS TLVs in
LSR WG drafts.

Cheers, Sue Hares




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

Re: [Lsr] Handling multiple Extended IS Reachability TLVs for a link

[Huzhibo]

Hi Everyone:

I think it is necessary to specify the key of the TLV and the information that 
needs to be carried repeatedly in this document. I am not sure that everyone 
has the same understanding of the key. If different vendors have different 
understandings of the key, there may be interoperability problems.

Thanks

Zhibo

From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Ketan Talaulikar
Sent: Thursday, June 30, 2022 11:15 AM
To: Les Ginsberg (ginsberg) 
Cc: Tony Li ; draft-pkaneria-lsr-multi-...@ietf.org; lsr 

Subject: Re: [Lsr] Handling multiple Extended IS Reachability TLVs for a link

Hi Les,

Please check inline below.

On Wed, Jun 29, 2022 at 11:05 PM Les Ginsberg (ginsberg) 
mailto:ginsb...@cisco.com>> wrote:
Ketan –

To add to what Tony has said…one thing which we did not want this draft to 
become was for it to be the place where a definition of the “key” for every TLV 
was defined.

KT> I agree.

Perhaps in the text you quote “MUST” should not be capitalized as we are simply 
describing the generic logic required.

KT> I think it would be better for the first part of the draft to just describe 
the general rules/logic for handling these cases. This part should stand on its 
own. Whether it needs to be normative or not, can be discussed later. IMHO, if 
normative language is better and the text can be worked out as the document 
progresses.


It is also worth pointing out that this draft is not defining new behavior nor 
is it extending the protocol in any way.

KT> I don't fully agree with that ...

The use of multiple TLVs for a given object is already implemented and deployed 
by multiple vendors and does not require any protocol extensions.

KT> I agree that this problem has been around for some time now. I agree that 
there are implementations that have "worked out a solution" and that they are 
also deployed. There aren't that many ways to tackle this after all ;-) ... 
that said, this handling is not yet specified in an RFC or ISO document, right? 
If not then, IMHO, this is an extension of the protocol behavior.

Given the increasing need for using multiple TLVs, it seemed prudent to 
document the generic behavior – which is the motivation for this draft.

KT> Agree. Also agree at a high level with the proposal. Again, there are not 
too many different ways to go about this :-)

But there is no intent to discuss all possible TLVs to which this behavior 
might apply.

KT> Agree

If you expect that then I think we are not in sync.

It has been discussed that the most common cases where multiple TLVs are likely 
to be required are the Prefix Reachability TLVs and the IS Neighbor TLVs. As 
such, it might not be a bad idea to discuss these two cases (the draft already 
discusses Prefix Reachability).

KT> For most TLVs/sub-TLVs, I believe the "keys" are part of the fixed form and 
hence the problem (unspecified keys) that I mentioned in my first email on this 
thread does not arise. There are though, some TLVs, where the keys remain 
unspecified and I strongly believe that (at least the most important of those?) 
need to be tackled in this document for it to help implementors.

Thanks,
Ketan


   Les

From: Ketan Talaulikar mailto:ketant.i...@gmail.com>>
Sent: Wednesday, June 29, 2022 9:33 AM
To: Tony Li mailto:tony...@tony.li>>
Cc: 
draft-pkaneria-lsr-multi-...@ietf.org;
 lsr mailto:lsr@ietf.org>>
Subject: Re: Handling multiple Extended IS Reachability TLVs for a link

Hi Tony,

No. It does not work. Take the following text from Sec 4.


   If this is insufficient sub-TLV space, then the node MAY advertise

   additional instances of the Extended IS Reachability TLV.  The key

   information MUST be replicated identically and the additional sub-TLV

   space may be populated with additional information.  The complete

   information for a given key in such cases is the joined set of all

   the carried information under the key in all the TLV instances.

There is a normative MUST there, but the "key information" is unspecified. 
Without that information these rules would not be really useful for 
implementation, would they?

I agree with the challenge of trying to catalog "keys" and "rules" on a per 
TLV/sub-TLV basis. Perhaps starting with the more widely used TLVs/sub-TLVs 
that are likely to exceed limits would be better than not covering any of them?

Thanks,
Ketan

On Wed, Jun 29, 2022 at 9:53 PM Tony Li 
mailto:tony...@tony.li>> wrote:

Hi Ketan,

We are hoping to not be that detailed in this document.  As soon as we become a 
catalog of LSPs, then the applicability of our statements is weakened with 
respect to TLVs that aren’t in the catalog.

What we’re trying to accomplish is to write some general rules that we all 
understand that apply uniformly across all TLVs that don’t specify their own 
overflow mechanisms.

Does this work for you?

Tony


> On Jun 29, 2022, at 6:47 AM, Ketan Talaulikar 
> mailto:ketant.i...@gmail.com>>