Hello Eduard,
Thanks for your comments.
Please see in line Yao>>.
Regards,
Yao
------------------原始邮件------------------
发件人：EduardMetz
抄送人：[email protected];
日 期 ：2021年06月29日 16:08
主 题 ：Re: [bess] Fw:New Version Notification for
draft-lz-bess-srv6-service-capability-00.txt
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 corr
esponds to an existing MPLS label, or (2) be dropped, in case the value of
sid-1 does not correspond to an allocated MPLS label.
Yao>> Agree with your analysis. I'll update this section accordingly.
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)?
Yao>>It's true that if PE2 supports SRv6 only, it wouldn't receive MPLS packets
since there's no LSP between PE1 and PE2. The description in this section about
PE2 may receive unexpected MPLS packets is incorrect, I'll modify it. Thanks
for point it out.
The main idea of this example scenario is that PE1 may receive SRv6 service
routes from PE2 which supports SRv6 only. The possible behaviors of PE1 are 1)
not sending packets to PE2 2) sending IPv6 packets to PE2 if there's route to
it.
Besides, I don't quite understand "BGP peerings (all IPv6)", do you mean that
all PEs use IPv6 addresses to establish neighbors, including legacy devices
like PE1? If this is the case, this draft is still applicable.
"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) .
Yao>> By adding this section I mean that defining new AFI/SAFIs can solve this
problem but it's totally another story. Maybe I can add some clarification in
case the readers feel confused about this part.
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
