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

["Pengshuping (Peng Shuping)" <[e-mail]>]

Hi Sue,

Please find the answers to your questions below.

From: Susan Hares [mailto:[e-mail]]
Sent: Monday, November 9, 2020 5:37 PM
To: Pengshuping (Peng Shuping) <[e-mail]>; 'Stephane Litkowski (slitkows)' <slitkows=[e-mail]>; [e-mail]
Subject: RE: [Idr] WG Adoption for draft-zhu-idr-bgp-ls-path-mtu (11/1/2020 to 11/16/2020)

Shuping:

A few questions about the scope of the Link MTU that

<individual contributors hat on>

I have few questions application of the Link MTU to non-IGP situations:
1) Can the Link MTU be passed across a local link upon with a NLRI source (protocol ID: direct or static)?

Yes, it can be done.

2) Can the Link MTU be passed if the link is a tunnel whose encapsulation is passed by the BGP's tunnel encapsulation attribute (draft-ietf-idr-tunnel-encaps-19.txt)?

Yes, it can be done as well. The link MTU TLV defined in this draft is general and can also be used for the tunnel case. As to whether and when to add this case, we would like to follow the WG's suggestion.

3) If the answer to question 2 is yes, could you provide me with an example topology where you envision this might happen.

The example topology could be that a BSID of one SR policy is used as one segment in another SR policy.

4) If the answer to question 2 is yes,  it possible that the link MTU is passed for a tunnel of SR policy tunnel type (see draft-ietf-segment-routing-te-policy-09.txt)?   If so, is the Link MTU a composite value that works for all segments?

Yes, in this case, the link MTU would be a tunnel MTU.


Thank you!

Best regards,
Shuping


Thank you, Sue
 <individual contributors hat off>


will pass an SR policy tunnel type for the BGP attribute (draft-ietf-idr-segement-routing-te-policy-09) that refers to a tunnel which



From: Idr [mailto:[e-mail]] On Behalf Of Pengshuping (Peng Shuping)
Sent: Wednesday, November 4, 2020 9:23 AM
To: Stephane Litkowski (slitkows); Susan Hares; [e-mail]<mailto:[e-mail]>
Subject: Re: [Idr] WG Adoption for draft-zhu-idr-bgp-ls-path-mtu (11/1/2020 to 11/16/2020)

Hi Stephane,

It has been included in this draft that "[RFC7176] specifies the ISIS mechanism and extensions for link MTU Sub-TLV" which can feed BGP-LS. This was actually suggested by the LSR WG.

Regarding OSPF, people can post corresponding draft to LSR if there is a need. There could be other ways too as you mentioned.

Best regards,
Shuping

From: Idr [mailto:[e-mail]] On Behalf Of Stephane Litkowski (slitkows)
Sent: Wednesday, November 4, 2020 4:03 PM
To: Susan Hares <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: Re: [Idr] WG Adoption for draft-zhu-idr-bgp-ls-path-mtu (11/1/2020 to 11/16/2020)

Hi,

"a) Are there ways to pass IGP link MTUs in
the IGPs?  If so, is this needed in BGP-LS"

This is a valid point, most of the time BGP-LS is feeded by IGP LSDBs (of course there are other ways too). While I see that IS-IS has some MTU subTLV coming from TRILL RFC7176 (possibly never been implemented), I don't see anything for OSPF (I'm not an OSPF expert, so I may have missed it).
Shouldn't this be checked and validated with LSR WG before adopting ?


Stephane


From: Idr <[e-mail]<mailto:[e-mail]>> On Behalf Of Susan Hares
Sent: lundi 2 novembre 2020 06:04
To: [e-mail]<mailto:[e-mail]>
Subject: [Idr] WG Adoption for draft-zhu-idr-bgp-ls-path-mtu (11/1/2020 to 11/16/2020)

This begins a 2 week WG adoption call for
draft-zhu-idr-bgp-ls-path-mtu-04.txt (11/1 - 11/16/2020).

The authors should send in an IPR statement for this draft
by 11/5 so the WG can include the IPR status in their decision.

You can access the draft at:
https://datatracker.ietf.org/doc/draft-zhu-idr-bgp-ls-path-mtu/

Since this draft is reference by an existing IDR draft
I've included a bit of background below to help you place
this draft into the larger context of the SR additions to BGP-LS
and the draft-ietf-idr-tunnel-encaps-19.txt.

This draft does continue BGP-LS additions.  if you
are opposed to any BGP-LS additions rather than
this specific addition, please make that clear in your
comment in this discussion.

The authors requested a WG adoption at IETF 108.
The IDR co-chairs thank the authors for their patience.
This draft has been delayed by process of having a
new document shepherd (Sue Hares) come up to speed
on draft-ietf-idr-tunnel-encapsulation.

Cheers, Sue

Background
===========
Segment Routing technology creates SR tunnels that are
directly overlaid on MPLS or SRv6.  While existing MPLS technology
(LDP and RSV-TE) provides mechanisms to negotiate path MTU
based on individual link MTU limits, the Segment Routing (SR)
on BGP-LS Link Attribute does not pass information on
MTU size per link.

draft-ietf-idr-sr-policy-path-mtu-02.txt sends PATH MTU
information in the tunnel-encapsulation attribute for the tunnel type
SR-Policy that handles segment routing (SR) paths.
However, it lacks the information to create a reasonable
Path size since the BGP-LS Link Attribute does distribute
this information.

The draft proposes adding a new sub-TLV for MTU size
to the BGP-LS Link Attribute TLV, and
draft-ietf-idr-sr-policy-path-mtu-02.txt mentions this
draft as one possible way to distribute the per link
MTU.

Questions for the authors might be:
a) Are there ways to pass IGP link MTUs in
the IGPs?  If so, is this needed in BGP-LS

b) What other mechanisms pass link MTU?