> -----邮件原件----- > 发件人: [email protected] [mailto:[email protected]] 代表 Robert Raszuk > 发送时间: 2014年5月22日 9:33 > 收件人: Xuxiaohu > 抄送: Yakov Rekhter; [email protected]; Hannes Gredler; John G. Scudder; Alvaro > Retana (aretana) > 主题: Re: 答复: [spring] 答复: 答复: 答复: draft-gredler-spring-mpls-05.txt as > SPRING WG document > > Yes I did not draw another targetted session, but this is not the point.
No matter whether R2 has another T-LDP session or not, the label 33 learnt from the T-LDP session with R3 should not be deemed as an incoming label. Incoming labels should always be those labels allocated by R2 itself. > You can't put for a given prefix multiple incoming labels in LFIB. > Only what is in the RIB from single protocol is installed in LFIB. Why can't? It's absolutely a local implementation issue. If the implementation doesn't support interoperation between different label distribution protocols, the implementation should have separate LFIB entries for each distribution protocol. In this way, there are still multiple LFIB (MPLS2MPLS) entries for a given prefix anyway. Of course, there could be only one FTN (IP2MPLS) mapping entry since one label distribution protocol is preferred to others. Best regards, Xiaohu > So you can't have both 1033 and 44 in the LFIB. > Rgs, > R. > > On Thu, May 22, 2014 at 3:27 AM, Xuxiaohu <[email protected]> wrote: > > Hi Robert, > > > > On R2, the label 33 learnt from T-LDP should be the outgoing label, rather > than the ingoing label for FEC 3.3.3.3/32, one of the incoming labels for FEC > 3.3.3.3/32 should be 1033. Another incoming label for FEC 3.3.3.3/32 is a > label > (e.g., 44) allocated by the LDP module. In other word, when receiving a packet > with top label of either 1033 or 44, that top label would be swapped to 33. > > > > Best regards, > > Xiaohu > > > >> -----邮件原件----- > >> 发件人: spring [mailto:[email protected]] 代表 Robert Raszuk > >> 发送时间: 2014年5月21日 22:08 > >> 收件人: Xuxiaohu > >> 抄送: Yakov Rekhter; [email protected]; Hannes Gredler; John G. Scudder; > >> Alvaro Retana (aretana) > >> 主题: Re: [spring] 答复: 答复: 答复: draft-gredler-spring-mpls-05.txt as > >> SPRING WG document > >> > >> Hi Xu, > >> > >> Sure .. please see attached CONCRETE example. > >> > >> Best, > >> R. > >> > >> On Wed, May 21, 2014 at 10:38 AM, Xuxiaohu <[email protected]> > >> wrote: > >> > > >> > > >> >> -----邮件原件----- > >> >> 发件人: [email protected] [mailto:[email protected]] 代表 Robert > >> Raszuk > >> >> 发送时间: 2014年5月21日 16:12 > >> >> 收件人: Xuxiaohu > >> >> 抄送: Yakov Rekhter; Hannes Gredler; [email protected]; John G. > >> >> Scudder; Alvaro Retana (aretana) > >> >> 主题: Re: [spring] 答复: 答复: draft-gredler-spring-mpls-05.txt as > >> >> SPRING WG document > >> >> > >> >> Xu, > >> >> > >> >> You do not get the concept of global (domian wide) label. > >> > > >> > Maybe. > >> > > >> >> You can't attach to a packet SR header with labels (SIDs) learned > >> >> by ISIS and in the segment nodes use LDP learned labels for > >> >> forwarding in your > >> data plane. > >> > > >> > Why can't? Please give a CONCRETE example and then assert who don’t > >> > get the concept of MPLS and SR:) > >> > > >> > Best regards, > >> > Xiaohu > >> > > >> >> That's the issue with consistency of label for a given FEC > >> >> distributed by more then one protocol within your domain. > >> >> > >> >> Best, > >> >> R. > >> >> > >> >> On Wed, May 21, 2014 at 10:01 AM, Xuxiaohu <[email protected]> > >> >> wrote: > >> >> > No, I don't think so. As long as a label for a given 32/ or 128/ > >> >> > FEC is attached to > >> >> a packet, no matter from whichever label distribution protocol > >> >> this label is learnt, the packet would definitely be forwarded to > >> >> the node identified by that FEC along the shortest path. > >> >> > > >> >> > Could you give a concrete example to illustrate why the > >> >> > forwarding result is > >> >> rather poor? > >> >> > > >> >> > Best regards, > >> >> > Xiaohu > >> >> > > >> >> >> -----邮件原件----- > >> >> >> 发件人: [email protected] [mailto:[email protected]] 代表 > Robert > >> >> Raszuk > >> >> >> 发送时间: 2014年5月21日 15:41 > >> >> >> 收件人: Xuxiaohu > >> >> >> 抄送: Hannes Gredler; [email protected]; Alvaro Retana (aretana); John > G. > >> >> >> Scudder; Yakov Rekhter > >> >> >> 主题: Re: [spring] 答复: draft-gredler-spring-mpls-05.txt as SPRING > >> >> >> WG document > >> >> >> > >> >> >> If your SR segments are to be engineered by set of SR headers > >> >> >> for a given FEC and anywhere in the network you will suddenly > >> >> >> choose LDP learned label for a given FEC the forwarding results > >> >> >> will be rather poor don't > >> >> you think ? > >> >> >> > >> >> >> r. > >> >> >> > >> >> >> On Wed, May 21, 2014 at 9:33 AM, Xuxiaohu > <[email protected]> > >> >> wrote: > >> >> >> > Robert, > >> >> >> > > >> >> >> >> -----邮件原件----- > >> >> >> >> 发件人: [email protected] [mailto:[email protected]] 代表 > >> Robert > >> >> >> Raszuk > >> >> >> >> 发送时间: 2014年5月21日 15:25 > >> >> >> >> 收件人: Xuxiaohu > >> >> >> >> 抄送: Hannes Gredler; Yakov Rekhter; [email protected]; Alvaro > >> >> >> >> Retana (aretana); John G. Scudder > >> >> >> >> 主题: Re: [spring] draft-gredler-spring-mpls-05.txt as SPRING > >> >> >> >> WG document > >> >> >> >> > >> >> >> >> Xiaohu, > >> >> >> >> > >> >> >> >> > Since there are just label distribution protocols which > >> >> >> >> > don't affect the route selection at all, why do you care > >> >> >> >> > about that consistency among > >> >> >> >> routers? > >> >> >> >> > >> >> >> >> We are talking about label selection and not route selection. > >> >> >> >> > >> >> >> >> This is about the same FEC so same route hence route > >> >> >> >> selection does not come to the picture. > >> >> >> > > >> >> >> > Sure. Then what's the problem if there is inconsistency of > >> >> >> > label selection > >> >> >> among routers (e.g., some routers prefer label bindings learnt > >> >> >> from ISIS while others prefer label bindings learnt from LDP)? > >> >> >> > > >> >> >> > Best regards, > >> >> >> > Xiaohu > >> >> >> > > >> >> >> >> Thx, > >> >> >> >> R. > >> >> >> > _______________________________________________ > >> >> >> > spring mailing list > >> >> >> > [email protected] > >> >> >> > https://www.ietf.org/mailman/listinfo/spring > >> >> > _______________________________________________ > >> >> > spring mailing list > >> >> > [email protected] > >> >> > https://www.ietf.org/mailman/listinfo/spring > >> > _______________________________________________ > >> > spring mailing list > >> > [email protected] > >> > https://www.ietf.org/mailman/listinfo/spring _______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
