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]; [email protected]; [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] | https://www.ietf.org/mailman/listinfo/spring
_______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
