Re: [Idr] [IDR] Questions regarding draft-ietf-idr-bgpls-srv6-ext

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

Hi Haibo,

My apologies since I seem to have missed responding to your email below. Please check inline below.

From: Wanghaibo (Rainsword) <[e-mail]>
Sent: 16 September 2019 13:11
To: Ketan Talaulikar (ketant) <[e-mail]>; [e-mail]
Cc: [e-mail]
Subject: RE: [IDR] Questions regarding draft-ietf-idr-bgpls-srv6-ext

Hi Ketan,

       Can you give explanation for my last question.

Thanks,
  Haibo

From: Wanghaibo (Rainsword)
Sent: Monday, August 12, 2019 11:54 AM
To: 'Ketan Talaulikar (ketant)' <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>
Subject: RE: [IDR] Questions regarding draft-ietf-idr-bgpls-srv6-ext

Hi Ketan,

  Thanks for your reply.

  Your explanation is very clear, but there is still a little doubt.

  1.  In this usage, when we create EPE for a single-hop neighbor, we must create two routes , one for the SRv6 SID NLRI  and another for the Link NLRI.
        In the previous method, we only need to report a PeerNode link NLRI
[KT] Actually, we would still have two NLRIs since the descriptors for PeerAdj SID is different from PeerNode SID as per the BGP-LS EPE draft.


  1.  In this new definition, a PeerSet may carry a large amount of Peer Node SID TLV, and it may cause the message to be too large.
[KT] Not really. It is just 16 byte per peer in the PeerSet. Also, when a packet with received with a PeerSet SID in the DA, what we need to do is load-balance across all Peers in that set. So I feel it more closely maps into the forwarding state as well.


In this way, the whole numbers NLRI will increase.
[KT] The main idea was to use the Link NLRI to describe the actual link in the link-state topology and not for the Peering session which may be single hop or multi-hop and may map to multiple underlying links/paths.
If it is multi-hop neighbors and all have joined to PeerSets, the number of routes added is equivalent to the number of PeerSets.
If it is single neighbor and all have joined to PeerSets, the number of added routes is equivalent to the number of neighbors plus the number of PeerSets.
[KT] If you see the NLRIs now more closely resemble the forwarding state on the router. So whether we have more NLRIs or less would dependent on how the sets are organized and we should consider the normal and not the worst theoretical case.

Do we have to support both options at the same time, or do we only use the one described now?
[KT] Not sure I follow what options you are referring to, but we can surely discuss perhaps in Singapore.

Thanks,
Ketan

Thanks,
Haibozuo

From: Ketan Talaulikar (ketant) [mailto:[e-mail]]
Sent: Friday, August 09, 2019 2:14 AM
To: Wanghaibo (Rainsword) <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>
Subject: RE: [IDR] Questions regarding draft-ietf-idr-bgpls-srv6-ext

Hi Haibo,

Thanks for your review and your comments. The draft proposal for how EPE SIDs are signalled for SRv6 do differ from how they are done for SR/MPLS. This change is based on our implementation and deployment experience - there was a potential to simplify the signalling of EPE SIDs for SRv6.

In a nutshell, the proposal is as follows:


  1.  PeerAdj SID is associated with an underlying interface to the connected peer. In almost every sense, it is similar to the IGP Adjacency SID. Hence, the SRv6 End.X SID TLV is used to advertise it (associated with Link NLRI) similar to how it’s done for PeerAdj SID for SR/MPLS. This part you have no issue/doubt about.
  2.  For the PeerNode and the PeerSet SIDs, in SR/MPLS case we created another BGP-LS Link NLRI that is separate from the one created for PeerAdj SID. This is because the link descriptors are different. They may be same or may not be same depending on whether the session is single-hop (i.e. using interface addresses for peering) or multi-hop (e.g. using loopback addresses for peering). Note in https://tools.ietf.org/html/draft-ietf-idr-bgpls-segment-routing-epe-19#section-4.2 that use of link local/remote IDs are MUST for PeerAdj SID but may not be available for the PeerNode SID for a multi-hop session.

This new/additional Link NLRI for the signalling of PeerNode and PeerSet SIDs is avoidable.

With SRv6, we have just a single PeerNode SID which is advertised as a SID associated with the Node. The SRv6 BGP Peer Node SID TLV indicates the remote peer information. So it will become:
NLRI : SRv6 SID NLRI1 (local node desc + SID1)  and with it in BGP-LS Attribute : Peer Node SID TLV (peer1)
NLRI : SRv6 SID NLRI2 (local node desc + SID2)  and with it in BGP-LS Attribute : Peer Node SID TLV (peer2)

Now, for the PeerSet SID, it is actually the same SID that is associated with multiple peers. This can be signalled using the same SRv6 BGP Peer Node SID TLV with the S flag set. So for a shared Set SID between two peers, it will become:
NLRI : SRv6 SID NLRI3 (local node desc + SID3) and with it in BGP-LS Attribute : Peer Node SID TLV (peer 1 + Sflag=set), Peer Node SID TLV (peer 2 + Sflag=set)

This seems more simpler and intuitive because we describing the SID and not mixing it up with links in a link-state topology representation.

The other alternative approach was to also advertise the SRv6 BGP Peer Node SID TLV along with the Link NLRI advertised for the End.X SID TLV corresponding to the PeerAdj SID without requiring additional Link NLRIs (with different descriptors) for the PeerNode and PeerSet SIDs.

I hope this clarifies and explains the reason for departure from EPE signalling done for SR/MPLS.

Feedback/suggestions are welcome.

Thanks,
Ketan

From: Wanghaibo (Rainsword) <[e-mail]<mailto:[e-mail]>>
Sent: 06 August 2019 15:43
To: [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>
Subject: [IDR] Questions regarding draft-ietf-idr-bgpls-srv6-ext

Hi authors,
     I have some questions about this draft, comment with blue words.



2.  BGP-LS Extensions for SRv6

   o  SRv6 End.X SID of the link state routing adjacency or the BGP EPE

      Peer Adjacency is advertised via a new SRv6 End.X SID TLV
// No doubt about this
   o  The BGP EPE Peer Node and Peer Set SID context is advertised via a
      new SRv6 BGP EPE Peer Node SID TLV
// Here use a new TLV to descripe peer node & peer set


7.2.  SRv6 BGP Peer Node SID TLV

   The BGP Peer Node SID and Peer Set SID for SR with MPLS dataplane are

   specified in [I-D.ietf-idr-bgpls-segment-routing-epe].  The similar

   Peer Node and Peer Set SID functionality can be realized with SRv6

   using the END.X SRv6 SID.  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.  This TLV MUST be included along with

   SRv6 End.X SID that is associated with the BGP Peer Node or Peer Set

   functionality.
// Here said the peer node sid followed by the SRv6 SID NLRI


6.  SRv6 SID NLRI



   A new "Link-State NLRI Type" is defined for SRv6 SID information as

   following:



   o  Link-State NLRI Type: SRv6 SID NLRI (value TBD see IANA

      Considerations Section 8.1).


     0                   1                   2                   3

     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

    +-+-+-+-+-+-+-+-+

    |  Protocol-ID  |

    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    |                        Identifier                             |

    |                        (64 bits)                              |

    ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|

    |               Local Node Descriptors (variable)              //

    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    |               SRv6 SID Descriptors (variable)                //

    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+





                      Figure 11: SRv6 SID NLRI Format
     // Here defined the SRv6 SID NLRI. If we use this NLRI, when we have more than one peer node,
   We may construct routes with:
   Route1: SRv6 SID NLRI1 (Local Node Desc + SID1) + Peer Node SID (peer1) + other Attr Tlv
   Route2: SRv6 SID NLRI2 (Local Node Desc + SID2) + Peer Node SID (peer2) + other Attr Tlv
   Why do we have to change to this? What are the benefits of this change?

   For draft draft-ietf-idr-bgpls-segment-routing-epe, the route will be
   Route1: Link NLRI1(Local Node Desc + peer1) + Peer Node SID (peer1) + other Attr Tlv
   Route2: Link NLRI2(Local Node Desc + peer2) + Peer Node SID (peer2) + other Attr Tlv

     Also in this format, when a peer join a peer set, how to create the route? Perhaps：
   Route1: SRv6 SID NLRI1 (Local Node Desc + SID1) + Peer Node SID (peer1) + other Attr Tlv
   Route2: SRv6 SID NLRI1 (Local Node Desc + SID2) + Peer Node SID (S-flag) + other Attr Tlv
   What’s the relationship about the two routes ?
   If there exist a route3:
   Route3: SRv6 SID NLRI1 (Local Node Desc + SID3) + Peer Node SID (S-flag) + other Attr Tlv
   Now the Peer node route1 belongs to route2’s Peer Set or route3’s Peer Set?

   But it’s clear for old mpls epe draft:
   Route1: Link NLRI1(Local Node Desc + peer1) + Peer Node SID (peer1) + Peer Set Sid(set1)+other Attr Tlv
   Route2: Link NLRI2(Local Node Desc + peer2) + Peer Node SID (peer2) + Peer Set Sid(set1)+ other Attr Tlv



Best Regards
Haibo