Re: [Lsr] [Idr] WG Adoption for draft-zhu-idr-bgp-ls-path-mtu (11/1/2020 to 11/16/2020)

[Ketan Talaulikar (ketant)]

Hi Zhibo,

I agree with everything that was discussed and concluded on that thread which 
you referred to.

It was about re-using existing sub-TLV for link MTU defined for Trill in ISIS. 
We are still saying the same thing! There is still the work required for the 
base ISIS procedures to be defined for the same.

Note that I did ask about the ISIS procedures for MTU during the last IETF 
online where the draft was presented. I was referred to the Trill spec at that 
time. But as we can clearly see those procedures are not applicable for normal 
ISIS.

Perhaps there was a misunderstanding somewhere in the middle that resulted in 
the approach that the authors took (i.e. assuming everything else was done and 
only BGP-LS remained) ?

In the thread the authors also spoke about OSPF but that seemed to have been 
dropped. As mentioned in my feedback, I am happy to help with if required.

Finally, I don’t see any opposition to the work itself or for it to be adopted 
(in due course). The discussion is on the “missing pieces” for this proposal to 
work and where this work is better accomplished.

Thanks,
Ketan

From: Huzhibo 
Sent: 14 November 2020 08:50
To: Les Ginsberg (ginsberg) ; Ketan Talaulikar (ketant) 
; Susan Hares ; 'Jeff Tantsura' 
; Stephane Litkowski (slitkows) ; 
i...@ietf.org; Acee Lindem (acee) 
Cc: lsr@ietf.org
Subject: 答复: [Idr] WG Adoption for draft-zhu-idr-bgp-ls-path-mtu (11/1/2020 to 
11/16/2020)

Hi Les, Acee:

Actually we have already discussed about this and reached agreements about two 
years ago. You may have forgotten. Please find the archives below.

https://mailarchive.ietf.org/arch/msg/lsr/C2bhd2ff2UJf4e_Gr-7j2W0g-SU/

I have followed your advice: "there already is a per link MTU sub-TLV defined 
by RFC 7176 ... in which case the existing sub-TLV is a perfect fit ...  IS-IS 
already has what is needed and therefore does not need any additional protocol 
extension". So we let our draft on ISIS extensions for MTU expired, i.e. 
draft-hu-lsr-isis-path-mtu. To be honest, I am a bit surprised when I saw your 
comments.

In this draft we focused on the extensions of BGP_LS for MTU only, which does 
not have to be feed by IGP LSDB. This draft has been discussed and revised a 
few rounds, based on the feedbacks both on ietf meetings and mail list, this 
document has good maturity to move forward.

Thanks
Zhibo


发件人: Idr [mailto:idr-boun...@ietf.org] 代表 Les Ginsberg (ginsberg)
发送时间: 2020年11月14日 7:58
收件人: Ketan Talaulikar (ketant) 
mailto:ketant=40cisco@dmarc.ietf.org>>; 
Susan Hares mailto:sha...@ndzh.com>>; 'Jeff Tantsura' 
mailto:jefftant.i...@gmail.com>>; 'Stephane Litkowski 
(slitkows)' 
mailto:slitkows=40cisco@dmarc.ietf.org>>;
 i...@ietf.org; 'Acee Lindem (acee)' 
mailto:acee=40cisco@dmarc.ietf.org>>
抄送: lsr@ietf.org
主题: Re: [Idr] WG Adoption for draft-zhu-idr-bgp-ls-path-mtu (11/1/2020 to 
11/16/2020)

The points which Ketan has made regarding the use of MTU advertisements defined 
in RFC 7176 are very valid. Indeed, the contents of the sub-TLV defined in 
https://www.rfc-editor.org/rfc/rfc7176.html#section-2.4 depend upon the TRILL 
specific MTU-probe/MTU-ack procedures defined in 
https://www.rfc-editor.org/rfc/rfc6325#section-4.4.3. These procedures are not 
currently applicable to non-TRILL environments.

So, there are no existing IGP advertisements defined which can support the 
goals of this draft.

As Ketan has also indicated, there is no discussion in the draft of how a BGP 
only network (for example) could provide the information of interest.

From my perspective, WG adoption of this draft in ANY WG is premature.
This might be a useful functionality to have – but at the moment we simply have 
an idea with no definition of how to implement/deploy it.

So I therefore oppose WG adoption of this draft by IDR.

Continuing the discussion is certainly useful – and I would encourage the 
current authors to investigate and propose relevant mechanisms in all the 
protocols of interest in some future version of the draft.
At that point we could then have a far more meaningful WG adoption call.

   Les


From: Idr mailto:idr-boun...@ietf.org>> On Behalf Of 
Ketan Talaulikar (ketant)
Sent: Friday, November 13, 2020 1:35 AM
To: Susan Hares mailto:sha...@ndzh.com>>; 'Jeff Tantsura' 
mailto:jefftant.i...@gmail.com>>; 'Stephane Litkowski 
(slitkows)' 
mailto:slitkows=40cisco@dmarc.ietf.org>>;
 i...@ietf.org; 'Acee Lindem (acee)' 
mailto:acee=40cisco@dmarc.ietf.org>>
Cc: lsr@ietf.org
Subject: Re: [Idr] WG Adoption for draft-zhu-idr-bgp-ls-path-mtu (11/1/2020 to 
11/16/2020)

Hi Authors,

I believe this work is useful and should be taken up. It has value in providing 
the link MTU as part of the topology information via BGP-LS. However, as 
pointed out by others on this thread, the draft should remain scoped to just 
that – i.e. providing link MTU information. The discussion related to Pa

[Lsr] 答复: [Idr] WG Adoption for draft-zhu-idr-bgp-ls-path-mtu (11/1/2020 to 11/16/2020)

[Huzhibo]

Hi Les, Acee:

Actually we have already discussed about this and reached agreements about two 
years ago. You may have forgotten. Please find the archives below.

https://mailarchive.ietf.org/arch/msg/lsr/C2bhd2ff2UJf4e_Gr-7j2W0g-SU/

I have followed your advice: "there already is a per link MTU sub-TLV defined 
by RFC 7176 ... in which case the existing sub-TLV is a perfect fit ...  IS-IS 
already has what is needed and therefore does not need any additional protocol 
extension". So we let our draft on ISIS extensions for MTU expired, i.e. 
draft-hu-lsr-isis-path-mtu. To be honest, I am a bit surprised when I saw your 
comments.

In this draft we focused on the extensions of BGP_LS for MTU only, which does 
not have to be feed by IGP LSDB. This draft has been discussed and revised a 
few rounds, based on the feedbacks both on ietf meetings and mail list, this 
document has good maturity to move forward.

Thanks
Zhibo


发件人: Idr [mailto:idr-boun...@ietf.org] 代表 Les Ginsberg (ginsberg)
发送时间: 2020年11月14日 7:58
收件人: Ketan Talaulikar (ketant) ; Susan Hares 
; 'Jeff Tantsura' ; 'Stephane 
Litkowski (slitkows)' ; i...@ietf.org; 
'Acee Lindem (acee)' 
抄送: lsr@ietf.org
主题: Re: [Idr] WG Adoption for draft-zhu-idr-bgp-ls-path-mtu (11/1/2020 to 
11/16/2020)

The points which Ketan has made regarding the use of MTU advertisements defined 
in RFC 7176 are very valid. Indeed, the contents of the sub-TLV defined in 
https://www.rfc-editor.org/rfc/rfc7176.html#section-2.4 depend upon the TRILL 
specific MTU-probe/MTU-ack procedures defined in 
https://www.rfc-editor.org/rfc/rfc6325#section-4.4.3. These procedures are not 
currently applicable to non-TRILL environments.

So, there are no existing IGP advertisements defined which can support the 
goals of this draft.

As Ketan has also indicated, there is no discussion in the draft of how a BGP 
only network (for example) could provide the information of interest.

From my perspective, WG adoption of this draft in ANY WG is premature.
This might be a useful functionality to have – but at the moment we simply have 
an idea with no definition of how to implement/deploy it.

So I therefore oppose WG adoption of this draft by IDR.

Continuing the discussion is certainly useful – and I would encourage the 
current authors to investigate and propose relevant mechanisms in all the 
protocols of interest in some future version of the draft.
At that point we could then have a far more meaningful WG adoption call.

   Les


From: Idr mailto:idr-boun...@ietf.org>> On Behalf Of 
Ketan Talaulikar (ketant)
Sent: Friday, November 13, 2020 1:35 AM
To: Susan Hares mailto:sha...@ndzh.com>>; 'Jeff Tantsura' 
mailto:jefftant.i...@gmail.com>>; 'Stephane Litkowski 
(slitkows)' 
mailto:slitkows=40cisco@dmarc.ietf.org>>;
 i...@ietf.org; 'Acee Lindem (acee)' 
mailto:acee=40cisco@dmarc.ietf.org>>
Cc: lsr@ietf.org
Subject: Re: [Idr] WG Adoption for draft-zhu-idr-bgp-ls-path-mtu (11/1/2020 to 
11/16/2020)

Hi Authors,

I believe this work is useful and should be taken up. It has value in providing 
the link MTU as part of the topology information via BGP-LS. However, as 
pointed out by others on this thread, the draft should remain scoped to just 
that – i.e. providing link MTU information. The discussion related to Path MTU 
and applicability to SR networks are best left outside the scope of this 
standards track draft.

Hi Sue,

I would support the points made by Acee for not taking up this draft in IDR WG 
and instead doing this in LSR.

Besides the missing coverage for OSPFv2/v3, there are also issues with how this 
would work with ISIS. The reference to the ISIS Trill specification points to 
this TLV https://tools.ietf.org/html/rfc7176#section-2.4 – if you see, there is 
more here than just the MTU value. What is more critical is the ISIS procedures 
(in non-Trill deployments) on how this value is determined. Please do not mix 
the following :

The MTU sub-TLV is used to optionally announce the MTU of a link as
   specified in [RFC6325], Section 
4.2.4.4.

Are the authors trying to specify that these Trill procedures for testing MTU 
need to be adopted for regular ISIS deployments.

My take is that while the ISIS TLV defined for Trill may be re-used in normal 
ISIS deployments, its usage and procedures need to be specified. Copying the 
LSR WG so that I may be corrected if I am wrong here.

Coming to the point of BGP-only networks, the draft has zero text related to 
that scenario. Moreover, the procedures for BGP-LS advertisements in BGP only 
fabric need to be specified as a base. The 
https://datatracker.ietf.org/doc/draft-ketant-idr-bgp-ls-bgp-only-fabric/ was 
my attempt to specify those procedures and it would be great if the IDR WG 
could review and provide feedback to this document and consider for adoption so 
we can cover the BGP-only networks.

I would also like to offer support/help

Re: [Lsr] [Idr] WG Adoption for draft-zhu-idr-bgp-ls-path-mtu (11/1/2020 to 11/16/2020)

[Jeff Tantsura]

To add to Les’s point of BGP only scenario, during MSD IESG reviews, BGP-LS 
only deployment was found not well characterized and had been removed from the 
draft. It will require much better discussion to have it included.

Regards,
Jeff

> On Nov 13, 2020, at 15:57, Les Ginsberg (ginsberg)  wrote:
> 
> 
> The points which Ketan has made regarding the use of MTU advertisements 
> defined in RFC 7176 are very valid. Indeed, the contents of the sub-TLV 
> defined in https://www.rfc-editor.org/rfc/rfc7176.html#section-2.4 depend 
> upon the TRILL specific MTU-probe/MTU-ack procedures defined in 
> https://www.rfc-editor.org/rfc/rfc6325#section-4.4.3. These procedures are 
> not currently applicable to non-TRILL environments.
>  
> So, there are no existing IGP advertisements defined which can support the 
> goals of this draft.
>  
> As Ketan has also indicated, there is no discussion in the draft of how a BGP 
> only network (for example) could provide the information of interest.
>  
> From my perspective, WG adoption of this draft in ANY WG is premature.
> This might be a useful functionality to have – but at the moment we simply 
> have an idea with no definition of how to implement/deploy it.
>  
> So I therefore oppose WG adoption of this draft by IDR.
>  
> Continuing the discussion is certainly useful – and I would encourage the 
> current authors to investigate and propose relevant mechanisms in all the 
> protocols of interest in some future version of the draft.
> At that point we could then have a far more meaningful WG adoption call.
>  
>Les
>  
>  
> From: Idr  On Behalf Of Ketan Talaulikar (ketant)
> Sent: Friday, November 13, 2020 1:35 AM
> To: Susan Hares ; 'Jeff Tantsura' ; 
> 'Stephane Litkowski (slitkows)' ; 
> i...@ietf.org; 'Acee Lindem (acee)' 
> Cc: lsr@ietf.org
> Subject: Re: [Idr] WG Adoption for draft-zhu-idr-bgp-ls-path-mtu (11/1/2020 
> to 11/16/2020)
>  
> Hi Authors,
>  
> I believe this work is useful and should be taken up. It has value in 
> providing the link MTU as part of the topology information via BGP-LS. 
> However, as pointed out by others on this thread, the draft should remain 
> scoped to just that – i.e. providing link MTU information. The discussion 
> related to Path MTU and applicability to SR networks are best left outside 
> the scope of this standards track draft.
>  
> Hi Sue,
>  
> I would support the points made by Acee for not taking up this draft in IDR 
> WG and instead doing this in LSR.
>  
> Besides the missing coverage for OSPFv2/v3, there are also issues with how 
> this would work with ISIS. The reference to the ISIS Trill specification 
> points to this TLV https://tools.ietf.org/html/rfc7176#section-2.4 – if you 
> see, there is more here than just the MTU value. What is more critical is the 
> ISIS procedures (in non-Trill deployments) on how this value is determined. 
> Please do not mix the following :
>  
> The MTU sub-TLV is used to optionally announce the MTU of a link as
>specified in [RFC6325], Section 4.2.4.4.
>  
> Are the authors trying to specify that these Trill procedures for testing MTU 
> need to be adopted for regular ISIS deployments.
>  
> My take is that while the ISIS TLV defined for Trill may be re-used in normal 
> ISIS deployments, its usage and procedures need to be specified. Copying the 
> LSR WG so that I may be corrected if I am wrong here.
>  
> Coming to the point of BGP-only networks, the draft has zero text related to 
> that scenario. Moreover, the procedures for BGP-LS advertisements in BGP only 
> fabric need to be specified as a base. The 
> https://datatracker.ietf.org/doc/draft-ketant-idr-bgp-ls-bgp-only-fabric/ was 
> my attempt to specify those procedures and it would be great if the IDR WG 
> could review and provide feedback to this document and consider for adoption 
> so we can cover the BGP-only networks.
>  
> I would also like to offer support/help to the authors in adding the 
> necessary OSPFv2/v3 support for the same in an LSR draft where we could 
> tackle both the IGPs and BGP-LS encoding and procedures together.
>  
> Thanks,
> Ketan
>  
> From: Idr  On Behalf Of Susan Hares
> Sent: 13 November 2020 00:20
> To: 'Jeff Tantsura' ; 'Stephane Litkowski 
> (slitkows)' ; i...@ietf.org; 'Acee 
> Lindem (acee)' 
> Subject: Re: [Idr] WG Adoption for draft-zhu-idr-bgp-ls-path-mtu (11/1/2020 
> to 11/16/2020)
>  
> Jeff and Authors of draft-zhu-idr-bgp-ls-path-mtu:
>  
> I do believe the authors agreed to renaming the draft.   
>  
> Does the name:   draft-xxx-idr-bgp-ls-link-mtu work for
> the authors and interested IDR participants.
>  
> As the end of 12 days of the 14 day WG LC, this draft appears
> to have general consensus from the WG as a useful draft.
>  
> I plan to allow 2 more days of comment, but at this point
> it appears the WG wishes to adopt this draft. 
>  
> Here’s my understanding of the best way forward:
>  
> If LSR adopts a version of the draft, IDR will allow the
> LSR

Re: [Lsr] [Idr] WG Adoption for draft-zhu-idr-bgp-ls-path-mtu (11/1/2020 to 11/16/2020)

[Les Ginsberg (ginsberg)]

The points which Ketan has made regarding the use of MTU advertisements defined 
in RFC 7176 are very valid. Indeed, the contents of the sub-TLV defined in 
https://www.rfc-editor.org/rfc/rfc7176.html#section-2.4 depend upon the TRILL 
specific MTU-probe/MTU-ack procedures defined in 
https://www.rfc-editor.org/rfc/rfc6325#section-4.4.3. These procedures are not 
currently applicable to non-TRILL environments.

So, there are no existing IGP advertisements defined which can support the 
goals of this draft.

As Ketan has also indicated, there is no discussion in the draft of how a BGP 
only network (for example) could provide the information of interest.

From my perspective, WG adoption of this draft in ANY WG is premature.
This might be a useful functionality to have – but at the moment we simply have 
an idea with no definition of how to implement/deploy it.

So I therefore oppose WG adoption of this draft by IDR.

Continuing the discussion is certainly useful – and I would encourage the 
current authors to investigate and propose relevant mechanisms in all the 
protocols of interest in some future version of the draft.
At that point we could then have a far more meaningful WG adoption call.

   Les


From: Idr  On Behalf Of Ketan Talaulikar (ketant)
Sent: Friday, November 13, 2020 1:35 AM
To: Susan Hares ; 'Jeff Tantsura' ; 
'Stephane Litkowski (slitkows)' ; 
i...@ietf.org; 'Acee Lindem (acee)' 
Cc: lsr@ietf.org
Subject: Re: [Idr] WG Adoption for draft-zhu-idr-bgp-ls-path-mtu (11/1/2020 to 
11/16/2020)

Hi Authors,

I believe this work is useful and should be taken up. It has value in providing 
the link MTU as part of the topology information via BGP-LS. However, as 
pointed out by others on this thread, the draft should remain scoped to just 
that – i.e. providing link MTU information. The discussion related to Path MTU 
and applicability to SR networks are best left outside the scope of this 
standards track draft.

Hi Sue,

I would support the points made by Acee for not taking up this draft in IDR WG 
and instead doing this in LSR.

Besides the missing coverage for OSPFv2/v3, there are also issues with how this 
would work with ISIS. The reference to the ISIS Trill specification points to 
this TLV https://tools.ietf.org/html/rfc7176#section-2.4 – if you see, there is 
more here than just the MTU value. What is more critical is the ISIS procedures 
(in non-Trill deployments) on how this value is determined. Please do not mix 
the following :

The MTU sub-TLV is used to optionally announce the MTU of a link as
   specified in [RFC6325], Section 
4.2.4.4.

Are the authors trying to specify that these Trill procedures for testing MTU 
need to be adopted for regular ISIS deployments.

My take is that while the ISIS TLV defined for Trill may be re-used in normal 
ISIS deployments, its usage and procedures need to be specified. Copying the 
LSR WG so that I may be corrected if I am wrong here.

Coming to the point of BGP-only networks, the draft has zero text related to 
that scenario. Moreover, the procedures for BGP-LS advertisements in BGP only 
fabric need to be specified as a base. The 
https://datatracker.ietf.org/doc/draft-ketant-idr-bgp-ls-bgp-only-fabric/ was 
my attempt to specify those procedures and it would be great if the IDR WG 
could review and provide feedback to this document and consider for adoption so 
we can cover the BGP-only networks.

I would also like to offer support/help to the authors in adding the necessary 
OSPFv2/v3 support for the same in an LSR draft where we could tackle both the 
IGPs and BGP-LS encoding and procedures together.

Thanks,
Ketan

From: Idr mailto:idr-boun...@ietf.org>> On Behalf Of 
Susan Hares
Sent: 13 November 2020 00:20
To: 'Jeff Tantsura' mailto:jefftant.i...@gmail.com>>; 
'Stephane Litkowski (slitkows)' 
mailto:slitkows=40cisco@dmarc.ietf.org>>;
 i...@ietf.org; 'Acee Lindem (acee)' 
mailto:acee=40cisco@dmarc.ietf.org>>
Subject: Re: [Idr] WG Adoption for draft-zhu-idr-bgp-ls-path-mtu (11/1/2020 to 
11/16/2020)

Jeff and Authors of draft-zhu-idr-bgp-ls-path-mtu:

I do believe the authors agreed to renaming the draft.

Does the name:   draft-xxx-idr-bgp-ls-link-mtu work for
the authors and interested IDR participants.

As the end of 12 days of the 14 day WG LC, this draft appears
to have general consensus from the WG as a useful draft.

I plan to allow 2 more days of comment, but at this point
it appears the WG wishes to adopt this draft.

Here’s my understanding of the best way forward:

If LSR adopts a version of the draft, IDR will allow the
LSR WG to be the main source as long as cross-working
review occurs so the BGP-only function can be reviewed.

Please continue to comment on the draft and
the planned progression.

Cheers,  Sue

From: Jeff Tantsura [mailto:jefftant.i...@gmail.com]
Sent: Thursday, November 12, 2020 12:53 PM
To: Susan Hares; Stephane Litkowski (slit

[Lsr] IPR Disclosure Huawei Technologies Co., Ltd's Statement about IPR related to draft-ietf-lsr-isis-srv6-extensions and draft-ietf-idr-bgpls-srv6-ext

[IETF Secretariat]

Dear Peter Psenak, Clarence Filsfils, Ahmed Bashandy, Bruno Decraene, Zhibo Hu:


An IPR disclosure that pertains to your Internet-Draft entitled "IS-IS
Extension to Support Segment Routing over IPv6 Dataplane"
(draft-ietf-lsr-isis-srv6-extensions) was submitted to the IETF Secretariat
on 2020-11-13 and has been posted on the "IETF Page of Intellectual Property
Rights Disclosures" (https://datatracker.ietf.org/ipr/4486/). The title of
the IPR disclosure is "Huawei Technologies Co.,Ltd's Statement about IPR
related to draft-ietf-lsr-isis-srv6-extensions and
draft-ietf-idr-bgpls-srv6-ext"


Thank you

IETF Secretariat


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

Re: [Lsr] [Idr] WG Adoption for draft-zhu-idr-bgp-ls-path-mtu (11/1/2020 to 11/16/2020)

[Ketan Talaulikar (ketant)]

Hi Authors,

I believe this work is useful and should be taken up. It has value in providing 
the link MTU as part of the topology information via BGP-LS. However, as 
pointed out by others on this thread, the draft should remain scoped to just 
that – i.e. providing link MTU information. The discussion related to Path MTU 
and applicability to SR networks are best left outside the scope of this 
standards track draft.

Hi Sue,

I would support the points made by Acee for not taking up this draft in IDR WG 
and instead doing this in LSR.

Besides the missing coverage for OSPFv2/v3, there are also issues with how this 
would work with ISIS. The reference to the ISIS Trill specification points to 
this TLV https://tools.ietf.org/html/rfc7176#section-2.4 – if you see, there is 
more here than just the MTU value. What is more critical is the ISIS procedures 
(in non-Trill deployments) on how this value is determined. Please do not mix 
the following :

The MTU sub-TLV is used to optionally announce the MTU of a link as
   specified in [RFC6325], Section 
4.2.4.4.

Are the authors trying to specify that these Trill procedures for testing MTU 
need to be adopted for regular ISIS deployments.

My take is that while the ISIS TLV defined for Trill may be re-used in normal 
ISIS deployments, its usage and procedures need to be specified. Copying the 
LSR WG so that I may be corrected if I am wrong here.

Coming to the point of BGP-only networks, the draft has zero text related to 
that scenario. Moreover, the procedures for BGP-LS advertisements in BGP only 
fabric need to be specified as a base. The 
https://datatracker.ietf.org/doc/draft-ketant-idr-bgp-ls-bgp-only-fabric/ was 
my attempt to specify those procedures and it would be great if the IDR WG 
could review and provide feedback to this document and consider for adoption so 
we can cover the BGP-only networks.

I would also like to offer support/help to the authors in adding the necessary 
OSPFv2/v3 support for the same in an LSR draft where we could tackle both the 
IGPs and BGP-LS encoding and procedures together.

Thanks,
Ketan

From: Idr  On Behalf Of Susan Hares
Sent: 13 November 2020 00:20
To: 'Jeff Tantsura' ; 'Stephane Litkowski (slitkows)' 
; i...@ietf.org; 'Acee Lindem (acee)' 

Subject: Re: [Idr] WG Adoption for draft-zhu-idr-bgp-ls-path-mtu (11/1/2020 to 
11/16/2020)

Jeff and Authors of draft-zhu-idr-bgp-ls-path-mtu:

I do believe the authors agreed to renaming the draft.

Does the name:   draft-xxx-idr-bgp-ls-link-mtu work for
the authors and interested IDR participants.

As the end of 12 days of the 14 day WG LC, this draft appears
to have general consensus from the WG as a useful draft.

I plan to allow 2 more days of comment, but at this point
it appears the WG wishes to adopt this draft.

Here’s my understanding of the best way forward:

If LSR adopts a version of the draft, IDR will allow the
LSR WG to be the main source as long as cross-working
review occurs so the BGP-only function can be reviewed.

Please continue to comment on the draft and
the planned progression.

Cheers,  Sue

From: Jeff Tantsura [mailto:jefftant.i...@gmail.com]
Sent: Thursday, November 12, 2020 12:53 PM
To: Susan Hares; Stephane Litkowski (slitkows); 
i...@ietf.org; Acee Lindem (acee)
Subject: Re: [Idr] WG Adoption for draft-zhu-idr-bgp-ls-path-mtu (11/1/2020 to 
11/16/2020)

+1 to everything Acee said

Cheers,
Jeff
On Nov 10, 2020, 1:01 PM -0800, Acee Lindem (acee) 
mailto:acee=40cisco@dmarc.ietf.org>>, 
wrote:
Speaking as an IDR WG member:

The name of the draft is wrong – the extension is for a Link MTU and not a path 
MTU.

Speaking as LSR Chair:

We could this in LSR as there is currently no MTU advertisement in the LSAs for 
OSPFv2 and OSPFv3. Implementations already make use of this information as it 
is used in the OSPF DBD packets and for LSA packing. Of course, we’d require a 
more accurate draft name and title.

Thanks,
Acee

From: Idr mailto:idr-boun...@ietf.org>> on behalf of 
Susan Hares mailto:sha...@ndzh.com>>
Date: Monday, November 9, 2020 at 4:20 PM
To: "'Stephane Litkowski (slitkows)'" 
mailto:slitkows=40cisco@dmarc.ietf.org>>,
 IDR List mailto:i...@ietf.org>>
Subject: Re: [Idr] WG Adoption for draft-zhu-idr-bgp-ls-path-mtu (11/1/2020 to 
11/16/2020)

Stephane:

My second message to this thread asked a few questions about the technology.

This information can be more than IGP information.   If SR segments statically 
defined (static or direct interfaces) tunnels and pass the endpoints via BGP 
tunnel-encaps draft with SR Policy tunnel type, this can just be BGP.

I’ll keep this WG adoption call going until we can be sure if:  1) it something 
LSR wants to standardize, and 2) whether there is a BGP only case.   It is 
clear to me that standardizing MTU for a SR segments with stacked tunnel 
segments passed by BGP was useful.

The authors should be the ones to propos