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 protected]] On Behalf Of Lizhenbin
Sent: Wednesday, January 28, 2015 3:06 AM
To: Hannes Gredler
Cc: [email protected]; [email protected]; [email protected]
Subject: [Teas] 答复: [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
