Hi Uma, Please refer to my inline comments.
Regards, Robin ________________________________ 发件人: Uma Chunduri [[email protected]] 发送时间: 2015年1月29日 12:01 收件人: Lizhenbin; Hannes Gredler 抄送: [email protected]; [email protected]; [email protected] 主题: RE: [spring] New Comments on Segment Routing(7): MTU Challenges for SR 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. From: mpls [mailto:[email protected]] On Behalf Of Lizhenbin Sent: Wednesday, January 28, 2015 3:06 AM To: Hannes Gredler Cc: [email protected]; [email protected]; [email protected] Subject: [mpls] 答复: [spring] New Comments on Segment Routing(7): MTU Challenges for SR 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 protected]] 发送时间: 2015年1月28日 4:01 收件人: Lizhenbin 抄送: [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> 主题: Re: [spring] New Comments on Segment Routing(7): MTU Challenges for SR 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 protected]<mailto:[email protected]> | https://www.ietf.org/mailman/listinfo/spring
_______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
