Re: [Idr] Adoption call for draft-ketant-idr-rfc7752bis-01.txt [8/8 to 8/22]

["Dongjie (Jimmy)" <[e-mail]>]

Hi Ketan,

Thanks for your prompt feedback.

In my understanding, RFC7752 defines a general mechanism to distribute link-state and TE information to the consumer, IGP is just one source of that information. Also please note that the text quoted from bgp-ls-epe draft references RFC7752.

That said, it may be helpful to add some text in rfc7752bis to indicate that the rules about node/link descriptors are applicable to the protocol-IDs defined in this document, the rules for other protocol-IDs will be defined in documents which introduce the protocol-ID.

Best regards,
Jie

From: Ketan Talaulikar (ketant) [mailto:[e-mail]]
Sent: Friday, August 09, 2019 10:57 AM
To: Dongjie (Jimmy) <[e-mail]>; Susan Hares <[e-mail]>; 'idr wg' <[e-mail]>
Subject: RE: [Idr] Adoption call for draft-ketant-idr-rfc7752bis-01.txt [8/8 to 8/22]

Hi Jie,

Thanks for your review and comments.

Let us note that RFC7752 was about pushing IGP link-state via BGP-LS and as such the link descriptors that it mentions are applicable in the scenario where the protocol is OSPF or IS-IS. The BGP EPE draft introduced the BGP protocol and specified the link descriptors for BGP peering links use case. As such, RFC7752 and BGP EPE are not in conflict or contradiction with each other.

This bis draft merely clarifies RFC7752 and is therefore scoped only for the IGP link-state propagation via BGP-LS.

Thanks,
Ketan

From: Idr <[e-mail]<mailto:[e-mail]>> On Behalf Of Dongjie (Jimmy)
Sent: 09 August 2019 08:14
To: Susan Hares <[e-mail]<mailto:[e-mail]>>; 'idr wg' <[e-mail]<mailto:[e-mail]>>
Subject: Re: [Idr] Adoption call for draft-ketant-idr-rfc7752bis-01.txt [8/8 to 8/22]

Hi,

In general I support the adoption of this document. It helps to clarify some confusions in RFC7752, and to solve some issues we realized during the progress of subsequent BGP-LS extensions.

And here are the comments I raised on the mic during IDR session in Montreal:

In section 4.2.2 of this -bis document, there are some changes to the encoding rules of link local/remote identifiers in the Link descriptors.

"    If interface and neighbor addresses, either IPv4 or IPv6, are
      present, then the IP address TLVs MUST be included and the Link
      Local/Remote Identifiers TLV MUST NOT be included in the Link
      Descriptor.  The Link Local/Remote Identifiers TLV MAY be included
      in the link attribute when available.

      If interface and neighbor addresses are not present and the link
      local/remote identifiers are present, then the Link Local/Remote
      Identifiers TLV MUST be included in the Link Descriptor."

While in draft-ietf-idr-bgpls-segment-routing-epe-19, section 4.2, it says:

" o  Link Descriptors MUST include the following TLV, as defined in
      [RFC7752]:

      *  Link Local/Remote Identifiers (TLV 258) contains the 4-octet
         Link Local Identifier followed by the 4-octet Link Remote
         Identifier.  The value 0 is used by default when the link
         remote identifier is unknown.

   o  Additional Link Descriptors TLVs, as defined in [RFC7752], MAY
      also be included to describe the addresses corresponding to the
      link between the BGP routers:

      *  IPv4 Interface Address (Sub-TLV 259) contains the address of
         the local interface through which the BGP session is
         established."

Thus it seems the above text in -7752bis is somewhat inconsistent with the bgp-ls-epe draft. Could this be considered in next revision of the bis draft, or the bgp-ls-epe draft? Thanks.

Best regards,
Jie

From: Idr [mailto:[e-mail]] On Behalf Of Susan Hares
Sent: Friday, August 09, 2019 3:31 AM
To: 'idr wg' <[e-mail]<mailto:[e-mail]>>
Subject: [Idr] Adoption call for draft-ketant-idr-rfc7752bis-01.txt [8/8 to 8/22]

This begins a 2 week adoption call for draft-ketant-idr-rfc7752bis-01.txt [8/8 to 8/22/2019]

In your comments please indicate "support" or "no support".

The chair and AD feel that a revision to RFC7752 is needed
to specify additional error handling.  Please consider
if this draft is a good place to start for this revision.

Cheerily, Susan Hares