Hello Yao, I think this could be a useful way to provide per-peer control in the co-existence use-cases and address some of the issues.
Some comment / questions (mainly editorial): If the allocation of SRv6 SIDs and MPLS labels on PE3 is not well planned, there may be a MPLS label label-2 whose value is exactly the same as the function and/or argument part of sid-1. In this case, the packets may be sent to the wrong destination, e.g, service 2. This suggests there should be some planning to align SRv6 SID and MPLS labels. I would say the starting point is that is not the case (or should be), I guess it could be done but this then imposes additional constraints on the SRv6 design / planning. Alignment may be done to have compatibility between MPLS and SRv6 (same values), this would avoid the situation described above, or it may be done to have separate numbering spaces, this would result in packet drop on PE3 (instead of wrong service), also an issue. Without alignment you could also have unintentional interconnect of different services. Alternative wording could be "Unless the allocation of SRv6 SIDs and MPLS labels on PE3 is aligned to ensure compatibility, the interpretation of the function/argument of the SRv6 SID (sid-1 in the example) will lead to incorrect forwarding of the traffic. In the example above, at PE packets may (1) be sent to the wrong service instance, in case the sid-1 function/argument value corresponds to an existing MPLS label, or (2) be dropped, in case the value of sid-1 does not correspond to an allocated MPLS label. The example scenario in the draft also includes PE2 which supports SRv6 only. Not sure if this is relevant for the use-case. PE1 and PE2 would not share a service between them. How would PE2 receive MPLS packets, if it does not support it (unless encapsulated in IPv6). Related to this, what are the assumptions with regard to BGP peerings (all IPv6)? "It's unrealistic to define new AFI/SAFIs for SRv6-based services to separate the advertisement of SRv6-based services and MPLS-based services completely, since this is a big change to the existing architecture." Do you see the SRv6 service capability as an alternative to having new AFI/SAFI? Maybe state that service capability allows BGP speakers to signal SRv6 support without requiring a new AFI/SAFI. The document already starts with the observation that existing AFI/SAFI are leveraged (instead of having separate) . cheers, Eduard On Fri, Jun 25, 2021 at 8:24 AM <[email protected]> wrote: > Hi all, > We have uploaded a new draft on "SRv6-based BGP Service Capability" . > This draft describes the problems that may be encountered during the > deployment of SRv6-based BGP services, mainly in the SRv6 and MPLS > co-existance scenario, and the possible solutions. > Any comments and suggestions are more than welcome. > > Best Regards, > Yao > > > > ------------------原始邮件------------------ > 发件人：[email protected] > 日 期 ：2021年06月25日 09:28 > 主 题 ：New Version Notification for > draft-lz-bess-srv6-service-capability-00.txt > > A new version of I-D, draft-lz-bess-srv6-service-capability-00.txt > has been successfully submitted by Liu Yao and posted to the > IETF repository. > Name: draft-lz-bess-srv6-service-capability > Revision: 00 > Title: SRv6-based BGP Service Capability > Document date: 2021-06-24 > Group: Individual Submission > Pages: 7 > URL: > https://www.ietf.org/archive/id/draft-lz-bess-srv6-service-capability-00.txt > Status: > https://datatracker.ietf.org/doc/draft-lz-bess-srv6-service-capability/ > Htmlized: > https://datatracker.ietf.org/doc/html/draft-lz-bess-srv6-service-capability > Abstract: > This draft describes the problems that may be encountered during the > deployment of SRv6-based BGP services and the possible solutions. > The IETF Secretariat_______________________________________________ > BESS mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/bess >
_______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
