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: Dongjie (Jimmy) <[e-mail]>
Sent: 06 November 2020 15:33
To: Ketan Talaulikar (ketant) <[e-mail]>; 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 Ketan,

Thanks for your clarification. Please find some further replies inline:

From: Ketan Talaulikar (ketant) [mailto:[e-mail]]
Sent: Friday, November 6, 2020 11:55 AM
To: Dongjie (Jimmy) <[e-mail]<mailto:[e-mail]>>; Susan Hares <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[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 Jie,

Please check inline below.

From: Idr <[e-mail]<mailto:[e-mail]>> On Behalf Of Dongjie (Jimmy)
Sent: 06 November 2020 08:20
To: Susan Hares <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[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.

[Jie] Please find the below text quoted from draft-ietf-idr-bgpls-segment-routing-epe, in which the peer node SID MUST be instantiated, while the peer Adj SID and peer Set SID MAY be instantiated.

" The following BGP Peering SIDs need to be instantiated on a BGP
   router for each of its BGP peer sessions that are enabled for Egress
   Peer Engineering:

   o  One PeerNode SID MUST be instantiated to describe the BGP peer
      session.

   o  One or more PeerAdj SID MAY be instantiated corresponding to the
      underlying link(s) to the directly connected BGP peer session.

   o  A PeerSet SID MAY be instantiated and additionally associated and
      shared between one or more PeerNode SIDs or PeerAdj SIDs."
[KT2] I stand corrected.


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.

[Jie] Based on the above text and the text in section 4.1, in case of SR-MPLS, the peer node SID and the associated link NLRI can provide the information about the BGP peer and the layer-3 link, thus still I'm not sure the peer adjacency SID with an additional link NLRI is needed. I agree their link descriptors are different, but in this case both link NLRIs are used to advertise the attributes of the same link.
[KT2] Yes, in that specific case, you are correct. However, that is not a generic statement. Please check https://tools.ietf.org/html/rfc8402#section-4.2 - the "interface/link" semantics are associated with the Peer Adjacency SID and not the Peer Node SID (very similar to IGP Node SID and IGP Adjacency SID).


  *   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).

[Jie] In my view the difference in SR-MPLS and SRv6 is due to the different treatment of the peer node SID and the peer adjacency SID.
[KT2] Yes. This is more clearly aligned with RFC8402.
With SR-MPLS, the peer node SID and its link NLRI represents a topological inter-domain "link" or connectivity in BGP, and the peer adj-SID can be used to further describe the underlying layer-3 links when needed (e.g. multiple L3 links used for a BGP session on loopback addresses). While with SRv6, the peer adjacency SID is used to represent each inter-domain layer-3 link, and peer node SID is not used as topological information any more.
[KT2] Please see my previous comment with references from RFC8402 where the BGP peering segments are defined.

Both approaches could work in this case, while one concern is do we need to keep the capability of describing an inter-domain "link" at BGP level?
[KT2] I am not sure that I understand. Can you please clarify?

Thanks,
Ketan

Best regards,
Jie


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