Sasha, SIDs are globally allocated and distributed. So, the answer to your question about P1, P2, P3 and P4 knowledge of the SID representing PE2 is "yes". Routers within the domain must know the SID representing PE2 (e.g.: 102).
Now, when it comes to the dataplane, it has to be understood that the label on top of the packet MAY have local significance and therefore MAY change at each hop according to mpls architecture. It is explained (succinctly, I admit) in section 3. This because the SID represents an index into a label space, not a label value. IOW, there is no requirement from SR to have globally assigned labels. The SR architecture makes use of globally assigned indexes onto locally scoped label space. This is, btw, what been implemented and currently (interop) tested. s. On Sep 29, 2014, at 2:28 PM, Alexander Vainshtein wrote: > Loa, and all, > I have read the draft and your review on the Wiki page, and I think that your > question about domain-wide labels is worth detailed discussion. > In Section 2 "Illustration", the draft says that: > - PE2 advertises (in the IGP) a host address 192.0.2.2/32 with its attached > node segment 102 > - PE1 installs the VPN prefix Z in the appropriate VRF and resolves the > next-hop onto the node segment 102. > Upon receiving a packet from A destined to Z, PE1 pushes two labels onto > the packet: the top label is 102, the bottom label is LZ. > 102 identifies the node segment to PE2 and hence transports the packet > along the ECMP-aware shortest- path to PE2. > > To me this strongly suggests that label 102 is understood by P1, P2, P3 and > P4 as a domain-wide label for an LSP that terminates in PE2. This looks > different from the downstream label allocation process as defined in RFC 3031 > and RFC 5331. > RFC 5331 clearly states in Section 4 "Upstream Label Assignment" that > <quote> > If the binding between L and F was made by a third party, say R3, and then > advertised to both Ru and Rd, we also refer to the label binding as > "upstream-assigned". > <end quote> > > In our case it seems that assignment of label 102 and its binding to FEC that > is represented by Segment 102 is performed by PE2, so P1, P2, P3 and P4 > should all treat this label as upstream-assigned. But this is never mentioned > in the draft. > > I concur with you that this requires discussion in the MPLS WG, and I am not > sure such a discussion should be postponed until the SPRING WG LC. > > I must admit that I did not read other SPRING documents (including one on > interoperability with existing label distribution protocols), and hence I can > be wrong in my conclusions. But the MPLS WG looks to me like exactly the > place where this should be clarified. > > My 2c, > Sasha > Email: [email protected] > Mobile: 054-9266302 > >> -----Original Message----- >> From: spring [mailto:[email protected]] On Behalf Of Loa Andersson >> Sent: Monday, September 29, 2014 1:56 PM >> To: [email protected] >> Cc: [email protected]; [email protected]; [email protected]; draft-filsfils-spring- >> [email protected]; <[email protected]>; mpls- >> [email protected] >> Subject: [spring] Routing Directorate QA review of draft-filsfils-spring- >> segment-routing-mpls >> >> Hello, >> >> I have been selected as the Routing Directorate QA reviewer for >> draft-filsfils- >> spring-segment-routing-mpls-03.txt. >> >> The Routing Directorate QA reviews are intended to be a support to improve >> the quality of RTG Area documents as the pass through the IETF process. >> >> This is the QA review at the time of wg document adoption poll. >> >> Document: draft-filsfils-spring-segment-routing-mpls-03.txt >> Reviewer: Loa Andersson >> Review Date: 2014-09-28 >> Working Group Adoption Poll end date: Oct 8, 2014 Intended Status: >> Standards Track >> >> Please find the review at: >> >> http://trac.tools.ietf.org/area/rtg/trac/wiki/QA%20review%20Sep%202014 >> >> /Loa >> >> -- >> >> >> Loa Andersson email: [email protected] >> Senior MPLS Expert [email protected] >> Huawei Technologies (consultant) phone: +46 739 81 21 64 >> >> _______________________________________________ >> 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
