Re: [Idr] IPR call and WG LC for draft-ietf-idr-bgpls-srv6-ext-04.txt (11/1/2020 to 11/16/2020)

["Ketan Talaulikar (ketant)" <[e-mail]>]

Hi Jie,

Please check inline below.

From: Idr <[e-mail]> On Behalf Of Dongjie (Jimmy)
Sent: 06 November 2020 08:20
To: Susan Hares <[e-mail]>; [e-mail]
Subject: Re: [Idr] IPR call and WG LC for draft-ietf-idr-bgpls-srv6-ext-04.txt (11/1/2020 to 11/16/2020)

Hi,

Yes, support with one question for clarification:

For SRv6 EPE, the Peer adjacency SID is advertised using SRv6 End.X SID TLV with BGP-LS Link NLRI, and this document says:

"The SRv6 End.X SID for the BGP Peer Adjacency indicates the cross-connect to a specific layer-3 link to the specific BGP session peer (neighbor)."

For the SRv6 EPE Peer Node SID, this document says:

"... the similar Peer Node and Peer Set functionality can be realized with SRv6 using the END.X behavior. The SRv6 BGP Peer Node SID TLV is an optional TLV for use in the BGP-LS Attribute for an SRv6 SID NLRI corresponding to BGP protocol."

My question is: for a BGP peer established using direct interface address, does this require both a peer adj-SID with BGP-LS Link NLRI and a peer node SID in SRv6 SID NLRI be advertised?
[KT] Yes.

 While with the mechanism of SR-MPLS EPE, my understanding is in this case advertising only the peer node SID would be enough, the peer adj-SID is optional and may be used for a multi-hop session with multiple underlying layer-3 links.
[KT] The SR-MPLS BGP EPE specification does not mandate the advertisement of any SID. It simply describes how to advertise them. In that sense, all of them are optional and the use-case/application determines which ones are required. It is the same in case of SRv6 BGP EPE. The differences between the two are the following:

  *   In case of SR-MPLS, both Adjacency and Node SIDs are advertised using their own separate/different BGP-LS Link NLRIs - this happens because their link descriptors are different. Please check sec 4.1 and 4.2.
  *   In case of SRv6, it is also advertised via different NLRIs - the Adjacency SID using the Link NLRI since it represents a topological link similar to IGPs. And the Node SID using the SRv6 SID NLRI since it does not represent a topological link but instead a peering session (that may go over one or more topological links or in some cases with multi-hop multiple nodes).
Hope that clarifies.

Thanks,
Ketan

Best regards,
Jie

From: Idr [mailto:[e-mail]] On Behalf Of Susan Hares
Sent: Monday, November 2, 2020 11:25 AM
To: [e-mail]<mailto:[e-mail]>
Subject: [Idr] IPR call and WG LC for draft-ietf-idr-bgpls-srv6-ext-04.txt (11/1/2020 to 11/16/2020)

This begins an IPR call and a 2 week WG LC for
draft-ietf-idr-bgpls-srv6-ext-04.txt (11/1 to 11/16/2020)

You can access the draft at:
https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-ls-flex-algo/

This draft focus on the BGP-LS support for SRv6.
Spring has proposed the SRv6 support in RFC8402
(see section 3.1.3 for mechanisms and section 8.2 for
Security considerations).

There are two implementations: Cisco and GoBGP
You can see the implementation report at:
https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgpls-srv6-ext%20implementations

In your responses, please consider the following questions:
a) Is the SRv6 technology ready for deployment or
are there known issues?

b) Will SRv6 provide valuable support for
deployments of BGP-LS in support of source routing
(aka spring)?

c) Is this draft ready for publication?

If you know of additional implementations, please send
a note to the idr chairs with the information or
respond to this email.

Cheers, Susan Hares