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
