Re: [Lsr] Question on draft-qgp-lsr-isis-pics-yang

[Shraddha Hegde]

I agree, the granularity would depend on the feature/RFC.

Another aspect I have seen in TLV implementations is, Receiving side processing 
is supported
But sending side isn’t. It may be useful to introduce this sending 
support/receiving support notion in the
Model.

Rgds
Shraddha



Juniper Business Use Only
From: Lsr  On Behalf Of Yingzhen Qu
Sent: Friday, November 17, 2023 4:28 AM
To: Tony Li 
Cc: Acee Lindem ; Les Ginsberg (ginsberg) 
; Loa Andersson ; lsr@ietf.org
Subject: Re: [Lsr] Question on draft-qgp-lsr-isis-pics-yang

[External Email. Be cautious of content]

Speaking as a co-author of the draft, I'm open to name suggestions.

As for granularity, I'd say this really varies per RFC/feature. We want to make 
it useful for operators but not too tedious to implement. Realistically, we 
won't be able to have modules for all existing RFCs, so it's more about new 
RFCs. The WG should decide the level of feature granularity as part of the 
document when it is to be published.

Thanks,
Yingzhen

On Thu, Nov 16, 2023 at 2:44 PM Tony Li 
mailto:tony...@tony.li>> wrote:
Hi Acee,

I concur that a simpler name is better and am fine with what you propose. Or 
pretty much anything other than ‘PICS’.  :-)

I disagree that feature level granularity is sufficient. Example: suppose an 
implementation supports traffic engineering. Is that sufficient for an 
operator? Is that enough to ensure interoperability? I’m not convinced. Does 
the node support administrative groups? What about extended administrative 
groups? Maybe we don’t need to be at the individual TLV level for every 
feature, but it sure would be nice to call out each and every option that an 
implementation may support.

Yes, I realize that it’s a giant hassle, but if we ever want to get to the 
world when network management is fully automated, we will need to make 
everything transparent.

Regards,
Tony



On Nov 16, 2023, at 2:32 PM, Acee Lindem 
mailto:acee.i...@gmail.com>> wrote:

Speaking as a WG contributor:

Hi Les,

I think a simpler name is better - perhaps ietf-isis-feature-support.yang with 
YANG prefix isis-fs would be better.  Which brings me to my next and more 
important point…

Like carbon neutrality, everyone at the LSR WG meeting who had an opinion 
thought such a YANG model would be operationally useful. However, I think the 
level of granularity is key. I believe that having a separate data node for 
each TLV/sub-TLV as was done in the example ietf-isis-pics-sr-mpls.yang module 
is way too granular to be useful. Rather, the YANG reporting should be done at 
the feature level. Also, does a distinction need to be made as to whether the 
IS-IS node supports the feature or both supports it and has it enabled (as 
would be the case for non-backward compatible features)?

Thanks,
Acee


On Nov 16, 2023, at 15:30, Les Ginsberg (ginsberg) 
mailto:40cisco@dmarc.ietf.org>> wrote:

Loa -

I agree with you that simply "IS-IS Support" may not be the best choice.
Although, the meeting minutes have not yet been posted, as I recall my response 
to Tony Li's suggestion of "IS-IS Support" was "Yes - something like that."

The draft authors have not yet discussed this - but we will and share the 
proposed new name.
Other suggestions welcomed.

  Les


-Original Message-
From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of Loa 
Andersson
Sent: Thursday, November 16, 2023 2:06 AM
To: lsr@ietf.org
Subject: [Lsr] Question on draft-qgp-lsr-isis-pics-yang

Working Group,

During the presentation of draft-qgp-lsr-isis-pics-yang there was a
rather strong opposition in the chat against using the ISO-term "PICS"
in an IETF document.

I think the term "Support" was suggested (excuse me if I missed
something), but I'm not that impressed, and would rather like to see
something like - "Supported Protocol Aspects".

/Loa
--
Loa Anderssonemail: l...@pi.nu
Senior MPLS Expert  
loa.pi...@gmail.com
Bronze Dragon Consulting phone: +46 739 81 21 64

___
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] Question on draft-qgp-lsr-isis-pics-yang

[Les Ginsberg (ginsberg)]

Acee –

Thanx for the comments – inline.

From: Acee Lindem 
Sent: Thursday, November 16, 2023 2:33 PM
To: Les Ginsberg (ginsberg) 
Cc: Loa Andersson ; lsr@ietf.org
Subject: Re: [Lsr] Question on draft-qgp-lsr-isis-pics-yang

Speaking as a WG contributor:

Hi Les,

I think a simpler name is better - perhaps ietf-isis-feature-support.yang with 
YANG prefix isis-fs would be better.  Which brings me to my next and more 
important point…
[LES:] My problem with “feature” in the name is that it suggests that the 
concept is not applicable to the base protocol – which isn’t the case.
Note that I am not suggesting (or even expecting) that we will introduce YANG 
to cover base protocol functionality – but it would be legitimate to do so.
But, I am not rejecting the suggestion – just sharing some thoughts.

Like carbon neutrality, everyone at the LSR WG meeting who had an opinion 
thought such a YANG model would be operationally useful. However, I think the 
level of granularity is key. I believe that having a separate data node for 
each TLV/sub-TLV as was done in the example ietf-isis-pics-sr-mpls.yang module 
is way too granular to be useful.
[LES:] I strongly disagree with that – and we chose SR-MPLS as the first 
example to illustrate why a simple Boolean is not sufficient. There are many 
real world examples of implementations that support portions of an RFC – but 
not its entirety.
In the case of SR-MPLS there are implementations that support IPv4 but not 
IPv6. There are implementations which don’t support SRMS advertisements. Etc.
This is important for operators to know when they are planning deployments.

Rather, the YANG reporting should be done at the feature level. Also, does a 
distinction need to be made as to whether the IS-IS node supports the feature 
or both supports it and has it enabled (as would be the case for non-backward 
compatible features)?

[LES:] The point was made that this has nothing to do with whether a feature 
has been enabled or not. The support information should be retrievable without 
even having instantiated an IS-IS instance on the router.
I believe this was further highlighted in the chat by a suggestion that this 
information could be retrievable from a vendor wiki.
We have config models to determine what is actually enabled.

   Les

Thanks,
Acee


On Nov 16, 2023, at 15:30, Les Ginsberg (ginsberg) 
mailto:ginsberg=40cisco@dmarc.ietf.org>>
 wrote:

Loa -

I agree with you that simply "IS-IS Support" may not be the best choice.
Although, the meeting minutes have not yet been posted, as I recall my response 
to Tony Li's suggestion of "IS-IS Support" was "Yes - something like that."

The draft authors have not yet discussed this - but we will and share the 
proposed new name.
Other suggestions welcomed.

  Les


-Original Message-
From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of Loa 
Andersson
Sent: Thursday, November 16, 2023 2:06 AM
To: lsr@ietf.org
Subject: [Lsr] Question on draft-qgp-lsr-isis-pics-yang

Working Group,

During the presentation of draft-qgp-lsr-isis-pics-yang there was a
rather strong opposition in the chat against using the ISO-term "PICS"
in an IETF document.

I think the term "Support" was suggested (excuse me if I missed
something), but I'm not that impressed, and would rather like to see
something like - "Supported Protocol Aspects".

/Loa
--
Loa Anderssonemail: l...@pi.nu
Senior MPLS Expert  
loa.pi...@gmail.com
Bronze Dragon Consulting phone: +46 739 81 21 64

___
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] Question on draft-qgp-lsr-isis-pics-yang

[Yingzhen Qu]

Speaking as a co-author of the draft, I'm open to name suggestions.

As for granularity, I'd say this really varies per RFC/feature. We want to
make it useful for operators but not too tedious to implement.
Realistically, we won't be able to have modules for all existing RFCs, so
it's more about new RFCs. The WG should decide the level of feature
granularity as part of the document when it is to be published.

Thanks,
Yingzhen

On Thu, Nov 16, 2023 at 2:44 PM Tony Li  wrote:

> Hi Acee,
>
> I concur that a simpler name is better and am fine with what you propose.
> Or pretty much anything other than ‘PICS’.  :-)
>
> I disagree that feature level granularity is sufficient. Example: suppose
> an implementation supports traffic engineering. Is that sufficient for an
> operator? Is that enough to ensure interoperability? I’m not convinced.
> Does the node support administrative groups? What about extended
> administrative groups? Maybe we don’t need to be at the individual TLV
> level for every feature, but it sure would be nice to call out each and
> every option that an implementation may support.
>
> Yes, I realize that it’s a giant hassle, but if we ever want to get to the
> world when network management is fully automated, we will need to make
> everything transparent.
>
> Regards,
> Tony
>
>
> On Nov 16, 2023, at 2:32 PM, Acee Lindem  wrote:
>
> Speaking as a WG contributor:
>
> Hi Les,
>
> I think a simpler name is better - perhaps ietf-isis-feature-support.yang
> with YANG prefix isis-fs would be better.  Which brings me to my next and
> more important point…
>
> Like carbon neutrality, everyone at the LSR WG meeting who had an opinion
> thought such a YANG model would be operationally useful. However, I think
> the level of granularity is key. I believe that having a separate data node
> for each TLV/sub-TLV as was done in the example ietf-isis-pics-sr-mpls.yang
> module is way too granular to be useful. Rather, the YANG reporting
> should be done at the feature level. Also, does a distinction need to be
> made as to whether the IS-IS node supports the feature or both supports
> it and has it enabled (as would be the case for non-backward compatible
> features)?
>
> Thanks,
> Acee
>
> On Nov 16, 2023, at 15:30, Les Ginsberg (ginsberg)  40cisco@dmarc.ietf.org> wrote:
>
> Loa -
>
> I agree with you that simply "IS-IS Support" may not be the best choice.
> Although, the meeting minutes have not yet been posted, as I recall my
> response to Tony Li's suggestion of "IS-IS Support" was "Yes - something
> like that."
>
> The draft authors have not yet discussed this - but we will and share the
> proposed new name.
> Other suggestions welcomed.
>
>   Les
>
> -Original Message-
> From: Lsr  On Behalf Of Loa Andersson
> Sent: Thursday, November 16, 2023 2:06 AM
> To: lsr@ietf.org
> Subject: [Lsr] Question on draft-qgp-lsr-isis-pics-yang
>
> Working Group,
>
> During the presentation of draft-qgp-lsr-isis-pics-yang there was a
> rather strong opposition in the chat against using the ISO-term "PICS"
> in an IETF document.
>
> I think the term "Support" was suggested (excuse me if I missed
> something), but I'm not that impressed, and would rather like to see
> something like - "Supported Protocol Aspects".
>
> /Loa
> --
> Loa Anderssonemail: l...@pi.nu
> Senior MPLS Expert  loa.pi...@gmail.com
> Bronze Dragon Consulting phone: +46 739 81 21 64
>
> ___
> 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
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Question on draft-qgp-lsr-isis-pics-yang

[Tony Li]

Hi Acee,

I concur that a simpler name is better and am fine with what you propose. Or 
pretty much anything other than ‘PICS’.  :-)

I disagree that feature level granularity is sufficient. Example: suppose an 
implementation supports traffic engineering. Is that sufficient for an 
operator? Is that enough to ensure interoperability? I’m not convinced. Does 
the node support administrative groups? What about extended administrative 
groups? Maybe we don’t need to be at the individual TLV level for every 
feature, but it sure would be nice to call out each and every option that an 
implementation may support.

Yes, I realize that it’s a giant hassle, but if we ever want to get to the 
world when network management is fully automated, we will need to make 
everything transparent.

Regards,
Tony


> On Nov 16, 2023, at 2:32 PM, Acee Lindem  wrote:
> 
> Speaking as a WG contributor: 
> 
> Hi Les, 
> 
> I think a simpler name is better - perhaps ietf-isis-feature-support.yang 
> with YANG prefix isis-fs would be better.  Which brings me to my next and 
> more important point… 
> 
> Like carbon neutrality, everyone at the LSR WG meeting who had an opinion 
> thought such a YANG model would be operationally useful. However, I think the 
> level of granularity is key. I believe that having a separate data node for 
> each TLV/sub-TLV as was done in the example ietf-isis-pics-sr-mpls.yang 
> module is way too granular to be useful. Rather, the YANG reporting should be 
> done at the feature level. Also, does a distinction need to be made as to 
> whether the IS-IS node supports the feature or both supports it and has it 
> enabled (as would be the case for non-backward compatible features)? 
> 
> Thanks, 
> Acee
> 
>> On Nov 16, 2023, at 15:30, Les Ginsberg (ginsberg) 
>>  wrote:
>> 
>> Loa -
>> 
>> I agree with you that simply "IS-IS Support" may not be the best choice.
>> Although, the meeting minutes have not yet been posted, as I recall my 
>> response to Tony Li's suggestion of "IS-IS Support" was "Yes - something 
>> like that."
>> 
>> The draft authors have not yet discussed this - but we will and share the 
>> proposed new name.
>> Other suggestions welcomed.
>> 
>>   Les
>> 
>>> -Original Message-
>>> From: Lsr  On Behalf Of Loa Andersson
>>> Sent: Thursday, November 16, 2023 2:06 AM
>>> To: lsr@ietf.org
>>> Subject: [Lsr] Question on draft-qgp-lsr-isis-pics-yang
>>> 
>>> Working Group,
>>> 
>>> During the presentation of draft-qgp-lsr-isis-pics-yang there was a
>>> rather strong opposition in the chat against using the ISO-term "PICS"
>>> in an IETF document.
>>> 
>>> I think the term "Support" was suggested (excuse me if I missed
>>> something), but I'm not that impressed, and would rather like to see
>>> something like - "Supported Protocol Aspects".
>>> 
>>> /Loa
>>> --
>>> Loa Anderssonemail: l...@pi.nu
>>> Senior MPLS Expert  loa.pi...@gmail.com
>>> Bronze Dragon Consulting phone: +46 739 81 21 64
>>> 
>>> ___
>>> 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] Question on draft-qgp-lsr-isis-pics-yang

[Acee Lindem]

Speaking as a WG contributor: 

Hi Les, 

I think a simpler name is better - perhaps ietf-isis-feature-support.yang with 
YANG prefix isis-fs would be better.  Which brings me to my next and more 
important point… 

Like carbon neutrality, everyone at the LSR WG meeting who had an opinion 
thought such a YANG model would be operationally useful. However, I think the 
level of granularity is key. I believe that having a separate data node for 
each TLV/sub-TLV as was done in the example ietf-isis-pics-sr-mpls.yang module 
is way too granular to be useful. Rather, the YANG reporting should be done at 
the feature level. Also, does a distinction need to be made as to whether the 
IS-IS node supports the feature or both supports it and has it enabled (as 
would be the case for non-backward compatible features)? 

Thanks, 
Acee

> On Nov 16, 2023, at 15:30, Les Ginsberg (ginsberg) 
>  wrote:
> 
> Loa -
> 
> I agree with you that simply "IS-IS Support" may not be the best choice.
> Although, the meeting minutes have not yet been posted, as I recall my 
> response to Tony Li's suggestion of "IS-IS Support" was "Yes - something like 
> that."
> 
> The draft authors have not yet discussed this - but we will and share the 
> proposed new name.
> Other suggestions welcomed.
> 
>   Les
> 
>> -Original Message-
>> From: Lsr  On Behalf Of Loa Andersson
>> Sent: Thursday, November 16, 2023 2:06 AM
>> To: lsr@ietf.org
>> Subject: [Lsr] Question on draft-qgp-lsr-isis-pics-yang
>> 
>> Working Group,
>> 
>> During the presentation of draft-qgp-lsr-isis-pics-yang there was a
>> rather strong opposition in the chat against using the ISO-term "PICS"
>> in an IETF document.
>> 
>> I think the term "Support" was suggested (excuse me if I missed
>> something), but I'm not that impressed, and would rather like to see
>> something like - "Supported Protocol Aspects".
>> 
>> /Loa
>> --
>> Loa Anderssonemail: l...@pi.nu
>> Senior MPLS Expert  loa.pi...@gmail.com
>> Bronze Dragon Consulting phone: +46 739 81 21 64
>> 
>> ___
>> 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] Question on draft-qgp-lsr-isis-pics-yang

[Les Ginsberg (ginsberg)]

Loa -

I agree with you that simply "IS-IS Support" may not be the best choice.
Although, the meeting minutes have not yet been posted, as I recall my response 
to Tony Li's suggestion of "IS-IS Support" was "Yes - something like that."

The draft authors have not yet discussed this - but we will and share the 
proposed new name.
Other suggestions welcomed.

   Les

> -Original Message-
> From: Lsr  On Behalf Of Loa Andersson
> Sent: Thursday, November 16, 2023 2:06 AM
> To: lsr@ietf.org
> Subject: [Lsr] Question on draft-qgp-lsr-isis-pics-yang
> 
> Working Group,
> 
> During the presentation of draft-qgp-lsr-isis-pics-yang there was a
> rather strong opposition in the chat against using the ISO-term "PICS"
> in an IETF document.
> 
> I think the term "Support" was suggested (excuse me if I missed
> something), but I'm not that impressed, and would rather like to see
> something like - "Supported Protocol Aspects".
> 
> /Loa
> --
> Loa Anderssonemail: l...@pi.nu
> Senior MPLS Expert  loa.pi...@gmail.com
> Bronze Dragon Consulting phone: +46 739 81 21 64
> 
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr

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

Re: [Lsr] draft-pkaneria-lsr-multi-tlv and "backwards compatibility"

[bruno . decraene]

Les,

Thanks for the reply.
Please see inline [Bruno2]



Orange Restricted
From: Les Ginsberg (ginsberg) 
Sent: Thursday, November 16, 2023 5:32 PM
To: DECRAENE Bruno INNOV/NET ; Christian Hopps 

Cc: lsr@ietf.org
Subject: RE: draft-pkaneria-lsr-multi-tlv and "backwards compatibility"

Bruno –

Thanx for the thoughtful comments.
Please see responses inline.

From: bruno.decra...@orange.com 
mailto:bruno.decra...@orange.com>>
Sent: Thursday, November 16, 2023 6:40 AM
To: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>; 
Christian Hopps mailto:cho...@chopps.org>>
Cc: lsr@ietf.org
Subject: RE: draft-pkaneria-lsr-multi-tlv and "backwards compatibility"

Les, all

Please see my 2 cents (operator’s feedback) inline [Bruno]
(to be clear, I’m not doing any comparison with any other proposal)



Orange Restricted
From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of Les 
Ginsberg (ginsberg)
Sent: Monday, November 6, 2023 4:13 PM
To: Christian Hopps mailto:cho...@chopps.org>>
Cc: lsr@ietf.org
Subject: Re: [Lsr] draft-pkaneria-lsr-multi-tlv and "backwards compatibility"


Chris -



Thanx for the reply - and glad to see we seem to be headed in the same 
direction.



Just wanted to clarify that the MP draft does NOT advocate partial deployment.



[Bruno] Speaking of clarity, I’d rephrase this as “does NOT support (enablement 
in) partial deployment”



[LES:] I think we need to pay attention to “scope” here.

The use cases related to Neighbor and Prefix Reachability TLVs are what has 
brought this issue to the forefront, but the scope of the MP-TLV draft is all 
codepoints to which MP applies.

For TLVs which are processed by all nodes in the network, partial deployment of 
MP support is simply not going to work.

But there are TLVs to which MP applies which may not be processed by all nodes 
in the network. In such cases, use of MP for those codepoints could be viable 
in the presence of nodes which don’t support MP so long as those nodes don’t 
need to process that codepoint at all.

Making a statement that partial deployment won’t work in all cases therefore 
isn’t accurate.



[Bruno2] You are correct of course. You are welcome to details those two cases 
in the draft.



No support of partial deployment makes this very difficult to deploy in certain 
environments.

You’d be surprised how old some platforms may be. And given that LSPs are 
flooded to all nodes (vs BGP attributes), in those environments, we are 
speaking of more than a decade between support on all implementation and 
deployment. Adding that some implementations may implement this latter, I’d say 
more than a decade (2 decades looks doable).



[LES:] Actually, I am not surprised by this at all. 😊

Part of my job is supporting old releases – even though I would wish that the 
customer would “just upgrade”.



[Bruno2] Yes, life would be simpler if customer would “just upgrade” or vendors 
would not move a platform to end of engineering 😉. But obviously both sides 
have constraints and we need to live with that.





https://www.ietf.org/archive/id/draft-pkaneria-lsr-multi-tlv-04.html#name-deployment-considerations
 recommends:



· Implementations provide a knob to control the use of MP-TLV

· Implementations report an alarm if an MP-TLV is received when use of 
MP-TLVs is disabled.

· Implementations report an alarm if local LSP generation requires the 
use of MP-TLVs when generation of MP-TLVs is disabled.



[Bruno] Good. Or minimal given the issues brought in case of partial 
deployment. Given that some implementors tends to skips “SHOULD”, I’d rather 
call for REQUIRED. (and I believe REQUIRED is the right level, at least for the 
first item)



[LES:] In principle I agree. But making a configuration knob or an alarm 
mandatory has some practical limitations.

One can (for example) say that a TLV format MUST follow certain constraints and 
enforce this on the receiver by saying if a malformed TLV is received it MUST 
be ignored.

But there is no enforcement mechanism for configuration knobs/alarms.

It is possible that a given implementation might define an alternate 
configuration mechanism that the owners believe meets the intention of the 
statements above but does not match the definitions – so the use normative 
language here makes me think we are overstepping.

While I agree with you in spirit, I am not sure that making the change you 
suggest is justifiable.

Happy to listen to WG feedback on this.

[Bruno2] I’m happy to rephrase the first requirement so that both of us are 
happy. Eg., Implementations MUST provide a way to disable generation of MP-TLVs.



Following these guidelines, MP-TLVs would only be present in a network when the 
control is set to use them AND the operator enters a config which requires 
sending more than 255 bytes. And violations of these conditions would be 
reported.



[Bruno] I don’t think that there is 

Re: [Lsr] draft-pkaneria-lsr-multi-tlv and "backwards compatibility"

[Les Ginsberg (ginsberg)]

Bruno –

Thanx for the thoughtful comments.
Please see responses inline.

From: bruno.decra...@orange.com 
Sent: Thursday, November 16, 2023 6:40 AM
To: Les Ginsberg (ginsberg) ; Christian Hopps 

Cc: lsr@ietf.org
Subject: RE: draft-pkaneria-lsr-multi-tlv and "backwards compatibility"

Les, all

Please see my 2 cents (operator’s feedback) inline [Bruno]
(to be clear, I’m not doing any comparison with any other proposal)



Orange Restricted
From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of Les 
Ginsberg (ginsberg)
Sent: Monday, November 6, 2023 4:13 PM
To: Christian Hopps mailto:cho...@chopps.org>>
Cc: lsr@ietf.org
Subject: Re: [Lsr] draft-pkaneria-lsr-multi-tlv and "backwards compatibility"


Chris -



Thanx for the reply - and glad to see we seem to be headed in the same 
direction.



Just wanted to clarify that the MP draft does NOT advocate partial deployment.



[Bruno] Speaking of clarity, I’d rephrase this as “does NOT support (enablement 
in) partial deployment”



[LES:] I think we need to pay attention to “scope” here.

The use cases related to Neighbor and Prefix Reachability TLVs are what has 
brought this issue to the forefront, but the scope of the MP-TLV draft is all 
codepoints to which MP applies.

For TLVs which are processed by all nodes in the network, partial deployment of 
MP support is simply not going to work.

But there are TLVs to which MP applies which may not be processed by all nodes 
in the network. In such cases, use of MP for those codepoints could be viable 
in the presence of nodes which don’t support MP so long as those nodes don’t 
need to process that codepoint at all.

Making a statement that partial deployment won’t work in all cases therefore 
isn’t accurate.



No support of partial deployment makes this very difficult to deploy in certain 
environments.

You’d be surprised how old some platforms may be. And given that LSPs are 
flooded to all nodes (vs BGP attributes), in those environments, we are 
speaking of more than a decade between support on all implementation and 
deployment. Adding that some implementations may implement this latter, I’d say 
more than a decade (2 decades looks doable).



[LES:] Actually, I am not surprised by this at all. 😊

Part of my job is supporting old releases – even though I would wish that the 
customer would “just upgrade”.





https://www.ietf.org/archive/id/draft-pkaneria-lsr-multi-tlv-04.html#name-deployment-considerations
 recommends:



· Implementations provide a knob to control the use of MP-TLV

· Implementations report an alarm if an MP-TLV is received when use of 
MP-TLVs is disabled.

· Implementations report an alarm if local LSP generation requires the 
use of MP-TLVs when generation of MP-TLVs is disabled.



[Bruno] Good. Or minimal given the issues brought in case of partial 
deployment. Given that some implementors tends to skips “SHOULD”, I’d rather 
call for REQUIRED. (and I believe REQUIRED is the right level, at least for the 
first item)



[LES:] In principle I agree. But making a configuration knob or an alarm 
mandatory has some practical limitations.

One can (for example) say that a TLV format MUST follow certain constraints and 
enforce this on the receiver by saying if a malformed TLV is received it MUST 
be ignored.

But there is no enforcement mechanism for configuration knobs/alarms.

It is possible that a given implementation might define an alternate 
configuration mechanism that the owners believe meets the intention of the 
statements above but does not match the definitions – so the use normative 
language here makes me think we are overstepping.

While I agree with you in spirit, I am not sure that making the change you 
suggest is justifiable.

Happy to listen to WG feedback on this.



Following these guidelines, MP-TLVs would only be present in a network when the 
control is set to use them AND the operator enters a config which requires 
sending more than 255 bytes. And violations of these conditions would be 
reported.



[Bruno] I don’t think that there is such “the operator enters a config which 
requires sending more than 255 bytes”. In my environment, a provisioning tool 
or a human would not know whether a given config would “require sending more 
than 255 bytes” or not. This would be too much complexity.

Not to mention that I guess that in the general case the config may be done on 
one node (e.g., a PE) and the advertisement requiring more than 255 octets 
could be done on a different node (e.g., ABR, L1/L2 router).

Finally, I would also assume that with zero config change from the operator, a 
software upgrade could have the limit being exceeded. (e.g., the new software 
advertising new sub-TLV, such as RFC 7794 “Prefix Attributes for Extended IPv4 
and IPv6 Reachability”).

IOW, let’s not put the blame on the operator when the issue is the spec (or 
feature) not supporting partial deployment.



[LES:] No intention on my part

Re: [Lsr] draft-pkaneria-lsr-multi-tlv and "backwards compatibility"

[bruno . decraene]

Les, all

Please see my 2 cents (operator's feedback) inline [Bruno]
(to be clear, I'm not doing any comparison with any other proposal)



Orange Restricted
From: Lsr  On Behalf Of Les Ginsberg (ginsberg)
Sent: Monday, November 6, 2023 4:13 PM
To: Christian Hopps 
Cc: lsr@ietf.org
Subject: Re: [Lsr] draft-pkaneria-lsr-multi-tlv and "backwards compatibility"


Chris -



Thanx for the reply - and glad to see we seem to be headed in the same 
direction.



Just wanted to clarify that the MP draft does NOT advocate partial deployment.



[Bruno] Speaking of clarity, I'd rephrase this as "does NOT support (enablement 
in) partial deployment"

No support of partial deployment makes this very difficult to deploy in certain 
environments.

You'd be surprised how old some platforms may be. And given that LSPs are 
flooded to all nodes (vs BGP attributes), in those environments, we are 
speaking of more than a decade between support on all implementation and 
deployment. Adding that some implementations may implement this latter, I'd say 
more than a decade (2 decades looks doable).





https://www.ietf.org/archive/id/draft-pkaneria-lsr-multi-tlv-04.html#name-deployment-considerations
 recommends:



* Implementations provide a knob to control the use of MP-TLV

* Implementations report an alarm if an MP-TLV is received when use of 
MP-TLVs is disabled.

* Implementations report an alarm if local LSP generation requires the 
use of MP-TLVs when generation of MP-TLVs is disabled.



[Bruno] Good. Or minimal given the issues brought in case of partial 
deployment. Given that some implementors tends to skips "SHOULD", I'd rather 
call for REQUIRED. (and I believe REQUIRED is the right level, at least for the 
first item)



Following these guidelines, MP-TLVs would only be present in a network when the 
control is set to use them AND the operator enters a config which requires 
sending more than 255 bytes. And violations of these conditions would be 
reported.



[Bruno] I don't think that there is such "the operator enters a config which 
requires sending more than 255 bytes". In my environment, a provisioning tool 
or a human would not know whether a given config would "require sending more 
than 255 bytes" or not. This would be too much complexity.

Not to mention that I guess that in the general case the config may be done on 
one node (e.g., a PE) and the advertisement requiring more than 255 octets 
could be done on a different node (e.g., ABR, L1/L2 router).

Finally, I would also assume that with zero config change from the operator, a 
software upgrade could have the limit being exceeded. (e.g., the new software 
advertising new sub-TLV, such as RFC 7794 "Prefix Attributes for Extended IPv4 
and IPv6 Reachability").

IOW, let's not put the blame on the operator when the issue is the spec (or 
feature) not supporting partial deployment.





Draft says "Sending of MP-TLVs in the presence of nodes which do not correctly 
process such advertisements can result in interoperablity issues, including 
incorrect forwarding of packets."



[Bruno]

While correct, I find the sentence a bit on the understatement side. In 
particular

:s/can result/is likely to result   (if not "will result")

:s/packets/a significant portion of the traffic resulting in persistent 
forwarding loops.



And thanks to Christian for the nice summary and bridging the communication gap.



--Bruno



   Les



> -Original Message-

> From: Christian Hopps mailto:cho...@chopps.org>>

> Sent: Monday, November 6, 2023 6:10 AM

> To: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>

> Cc: Christian Hopps mailto:cho...@chopps.org>>; 
> lsr@ietf.org

> Subject: Re: draft-pkaneria-lsr-multi-tlv and "backwards compatibility"

>

>

> My point is that people are not using the same definition of backward

> compatibility. This is why this argument over it is going in circles. I'm

> suggesting that when you consider each persons definition of backward

> compatibility, then neither side is wrong. So saying things like "No. You are

> wrong" etc, is not helpful to moving things forward.

>

> In both cases, when you actually need multi-part-tlv, you have to deploy the

> new software to all the routers that will use it; however the multi-part-tlv 
> draft

> allows for a messy sort of "it still works as long as you don't need 
> multi-part-

> tlv on routers that don't understand it" operation. So you hand craft your

> software deployment to match your network config to make that work.

>

> The Big TLV solution does not allow for this "messy but functioning

> deployment", and this is why I believe people prefer the multi-part TLV

> solution. That should be enough to move things forward IMO.

>

> Thanks,

> Chris.

> [wg-member]

>

> "Les Ginsberg (ginsberg)" mailto:ginsb...@cisco.com>> 
> writes:

>

> > Chris (and everyone) -

> >

> >

> >

> > A more complete response to your comment

[Lsr] Question on draft-qgp-lsr-isis-pics-yang

[Loa Andersson]

Working Group,

During the presentation of draft-qgp-lsr-isis-pics-yang there was a 
rather strong opposition in the chat against using the ISO-term "PICS" 
in an IETF document.


I think the term "Support" was suggested (excuse me if I missed 
something), but I'm not that impressed, and would rather like to see 
something like - "Supported Protocol Aspects".


/Loa
--
Loa Anderssonemail: l...@pi.nu
Senior MPLS Expert  loa.pi...@gmail.com
Bronze Dragon Consulting phone: +46 739 81 21 64

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