Subject: [mpls] New Comments on Segment Routing(7): MTU Challenges for SR

From: Lizhenbin <[email-masked]>
Date: Tue, 27 Jan 2015 11:24:23 +0000

Hi all authors of segment routing,

This is the seventh commens. The issues proposed here are for both SR-TE path and SR-BE path.

         1              1           1            1
  S11-----------S12----------S13---------S14---------S15
   |             |            |           |           |
  1|            1|           1|          1|          1|
   |             |            |           |           |
  S21-----------S22----------S23---------S24---------S25
         4              4           4            4

Still take the topology in the comment 6 as the example. No matter the loose explicit path or

the strict explicit path for the loose hop, assume the MTU of the interface is the same,

since the depth of the label stacks for the primary path and the backup path are different.

There is the risk that the effetive payload may transmit through the primary path, but may be

fragmented or dropped in the backup path. As the difference between the label stacks of the

primary path and the backup path increase, the risk will increase.

From the case, we can deduce that the risk may exists for any scenarios in which the same traffic

 may switch from one SR path to the other SR path. The SR path includes SR-TE path such as MPLS TE

hotstandby/reoptimization and SR-BE path such as TI-FRR.

Besides above issues, LDP/RSVP-TE can support the path MTU to track the MTU informaiton along the

LSP through signalling. Then the reasonable MTU info will be adopted in the ingress node. For both

 SR-TE path (if PCE is not used) and SR-BE path, since there is no signalling to advertise

the information. How to implement the feature? Or there maybe the risk that the packet may be

dropped by the nodes along the LSP.

Regards,

Robin

---

From: Hannes Gredler <[email-masked]>
Date: Tue, 27 Jan 2015 21:01:01 +0100

only can speak for IS-IS -
afaik the Trill extensions gave us a way of signaling the MTU of a link ...

so what we could do is to advertise the MTU for each adjacency and implement
proper fragmentation at the TE tunnel ingress.

/hannes

On Tue, Jan 27, 2015 at 11:24:23AM +0000, Lizhenbin wrote:
|    Hi all authors of segment routing,
| 
|    This is the seventh commens. The issues proposed here are for both SR-TE
|    path and SR-BE path.
| 
| 
| 
|             1              1           1            1
|      S11-----------S12----------S13---------S14---------S15
|       |             |            |           |           |
|      1|            1|           1|          1|          1|
|       |             |            |           |           |
|      S21-----------S22----------S23---------S24---------S25
|             4              4           4            4
| 
| 
| 
|    Still take the topology in the comment 6 as the example. No matter the
|    loose explicit path or
| 
|    the strict explicit path for the loose hop, assume the MTU of the
|    interface is the same,
| 
|    since the depth of the label stacks for the primary path and the backup
|    path are different.
| 
|    There is the risk that the effetive payload may transmit through the
|    primary path, but may be
| 
|    fragmented or dropped in the backup path. As the difference between the
|    label stacks of the
| 
|    primary path and the backup path increase, the risk will increase.
| 
| 
| 
|    From the case, we can deduce that the risk may exists for any scenarios in
|    which the same traffic
| 
|     may switch from one SR path to the other SR path. The SR path includes
|    SR-TE path such as MPLS TE
| 
|    hotstandby/reoptimization and SR-BE path such as TI-FRR.
| 
| 
| 
|    Besides above issues, LDP/RSVP-TE can support the path MTU to track the
|    MTU informaiton along the
| 
|    LSP through signalling. Then the reasonable MTU info will be adopted in
|    the ingress node. For both
| 
|     SR-TE path (if PCE is not used) and SR-BE path, since there is no
|    signalling to advertise
| 
|    the information. How to implement the feature? Or there maybe the risk
|    that the packet may be
| 
|    dropped by the nodes along the LSP.
| 
| 
| 
| 
| 
| 
| 
|    Regards,
| 
|    Robin

| _______________________________________________
| spring mailing list
| [email-masked]
| https://www.ietf.org/mailman/listinfo/spring

---

From: Lizhenbin <[email-masked]>
Date: Wed, 28 Jan 2015 11:06:01 +0000

Hi Hannes,

I have ever thought about the possible solutions based on the flooded MTU information through IGP.

There are still two possible issues:

1. Inter-area for SR-TE path: Maybe we not only introduce the IGP extensions, but also PCEP extensions.

2. For SR-BE path, it has to introduce the TE-like end-to-end path calculation at the ingress node.

My concern is not just for the possible solutions, but to explore the essence of SR which may has much

effect on its deployment comparing with the existing MPLS protocol. It will be explained in

the next comments.

Regards,

Robin

________________________________________
发件人: Hannes Gredler [[email-masked]]
发送时间: 2015年1月28日 4:01
收件人: Lizhenbin
抄送: [email-masked]; [email-masked]; [email-masked]
主题: Re: [spring] New Comments on Segment Routing(7): MTU Challenges for SR

/hannes

---

From: Gregory Mirsky <[email-masked]>
Date: Wed, 28 Jan 2015 23:26:58 +0000

Hi Robin, et. al,
pardon my naïve question Why Path MTU Discovery is not sufficient? I think that with Segment Routing it would be possible to construct the MTU Size matrix of the particular domain.

                Regards,
                                Greg

From: Teas [mailto:[email-masked]] On Behalf Of Lizhenbin
Sent: Wednesday, January 28, 2015 3:06 AM
To: Hannes Gredler
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: [Teas] 答复: [spring] New Comments on Segment Routing(7): MTU Challenges for SR

Hi Hannes,

the next comments.

Regards,

Robin

________________________________________
发件人: Hannes Gredler [[email-masked]]
发送时间: 2015年1月28日 4:01
收件人: Lizhenbin
抄送: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
主题: Re: [spring] New Comments on Segment Routing(7): MTU Challenges for SR

/hannes

| _______________________________________________
| spring mailing list
| [email-masked]<mailto:[email-masked]>
| https://www.ietf.org/mailman/listinfo/spring

---

From: Uma Chunduri <[email-masked]>
Date: Thu, 29 Jan 2015 04:01:40 +0000

Hi Robin,

If we have MTU issues with in an area, I see trouble in basic IGP functioning (for example it’s a serious issue with IS-IS for basic operation).
For inter area cases don’t you think it’s in PCE/Controller’s scope to setup paths based on the advertised MTU (yes, if MTU is advertised on ADJs as proposed below).

--
Uma C.

From: mpls [mailto:[email-masked]] On Behalf Of Lizhenbin
Sent: Wednesday, January 28, 2015 3:06 AM
To: Hannes Gredler
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: [mpls] 答复: [spring] New Comments on Segment Routing(7): MTU Challenges for SR

Hi Hannes,

the next comments.

Regards,

Robin

/hannes

---

From: Lizhenbin <[email-masked]>
Date: Thu, 29 Jan 2015 06:46:18 +0000

Hi Greg,

Please refer to my inline comments.

Regards,

Robin

________________________________
发件人: Gregory Mirsky [[email-masked]]
发送时间: 2015年1月29日 7:26
收件人: Lizhenbin; Hannes Gredler
抄送: [email-masked]; [email-masked]; [email-masked]
主题: RE: [spring] New Comments on Segment Routing(7): MTU Challenges for SR

Hi Robin, et. al,
pardon my naïve question Why Path MTU Discovery is not sufficient? I think that with Segment Routing it would be possible to construct the MTU Size matrix of the particular domain.
[Robin] My opinion is that the there is limitation for the path MTU discovery based on IGP.  For the inter-area and SR-BE path scenarios, therestill  need extra mechanisms. For the first scenario, it will increase the complexity of the solutions. For the second scenario, it may hurt fast convergence of best-effort path.

                Regards,
                                Greg

Hi Hannes,

the next comments.

Regards,

Robin

/hannes

---

From: Lizhenbin <[email-masked]>
Date: Thu, 29 Jan 2015 07:06:28 +0000

Hi Uma,

Regards,

Robin

发件人: Uma Chunduri [[email-masked]]
发送时间: 2015年1月29日 12:01

Hi Robin,

If we have MTU issues with in an area, I see trouble in basic IGP functioning (for example it’s a serious issue with IS-IS for basic operation).
[Robin] I agree with you that there exists the MTU issue for the routing functioning. But the MTU issue can be solved by the path MTU mechanism provided by LDP/RSVP-TE. My question is whether SR path based on the MPLS forwarding plane is the comparative with the routing or MPLS LSP.

For inter area cases don’t you think it’s in PCE/Controller’s scope to setup paths based on the advertised MTU (yes, if MTU is advertised on ADJs as proposed below).
[Robin] In fact, in the comments (8) I have explained the possible solutions. Do you think the solution is too complex for the path MTU of SR which could have be solved by the path MTU information exchange through only LDP or RSVP-TE while for the SR path it has to introduce IGP-based MTU advertisement, the end-to-end path MTU computation in the ingress node, and PCE-based end-to-end MTU information collection?  Even so, for SR-BE path, there is still challenges for the path MTU. Moreover, this is just for the path MTU. Taking into account more scenarios which needs the information exchanging along the nodes of LSP such as path recording, loop prevention, error handling and other existing features of LDP/RSVP-TE, what is possible complexity for SR solutions?

--
Uma C.

Hi Hannes,

the next comments.

Regards,

Robin

/hannes