Subject: [bess] Fw:New Version Notification for draft-lz-bess-srv6-service-capability-00.txt

From: <[email-masked]>
Date: Fri, 25 Jun 2021 14:23:30 +0800 (CST)

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-masked]
日 期 ：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

---

From: Eduard Metz <[email-masked]>
Date: Tue, 29 Jun 2021 10:07:13 +0200

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-masked]> wrote:

> deployment of SRv6-based BGP services, mainly in the SRv6 and MPLS
> co-existance scenario, and the possible solutions.
> 主 题 ：New Version Notification for
> draft-lz-bess-srv6-service-capability-00.txt
>
> 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:
> The IETF Secretariat_______________________________________________
> BESS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/bess
>

---

From: <[email-masked]>
Date: Wed, 30 Jun 2021 10:33:57 +0800 (CST)

Hello Eduard,

Thanks for your comments. 
Please see in line Yao>>.

Regards,
Yao

------------------原始邮件------------------
发件人：EduardMetz
抄送人：[email-masked];
日 期 ：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