Subject: [Idr] Opsdir early review of draft-ietf-idr-bgp-ls-segment-routing-ext-06

From: Joel Jaeggli <[email-masked]>
Date: Tue, 08 May 2018 23:45:34 -0700

Reviewer: Joel Jaeggli
Review result: Has Nits

I have performed a requested early review on the behalf of the operations
directorate of the current draft-ietf-idr-bgp-ls-segment-routing-ext-06.
Generally I think this document is good, I won't say ready, as this review is
intended as an early review not a final one.

Some nits

1-
introduction

   This way, all BGP speakers (specifically the route-reflectors) obtain
   Link-State information from all IGP areas (and from other ASes from
   EBGP peers).

* BGP speakers are agnostic about the source of the information beyond that it
was exported with certain properties from the rib of it’s neighbor.

2 -
   An external component (e.g., a controller) then can
   collect SR information in the "northbound" direction across IGP areas
   or ASes and construct the end-to-end path (with its associated SIDs)
   that need to be applied to an incoming packet to achieve the desired
   end-to-end forwarding.

* Unqualified use of the term northbound I find generally problematic,
particularly in the case of a route reflector. Previously RFC 7752 manged to
use the term in the title and then never again within the text.

3-

2.3.3.  Source Router Identifier (Source Router-ID) TLV

   The Source Router-ID TLV contains the IPv4 or IPv6 Router-ID of the
   originator of the Prefix.  For IS-IS protocol this is as defined in
   [RFC7794].  The Source Router-ID TLV may be used to carry the OSPF
   Router-ID of the prefix originator.

   The Source Router-ID TLV has the following format:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Type               |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   //                  IPv4/IPv6 Address (Router-ID)              //
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   where:

      Type: TBD, see Section 4.

      Length: 4 or 16.

      IPv4/IPv6 Address: 4 octet IPv4 address or 16 octet IPv6 address.

   The semantic of the Source Router-ID TLV is defined in [RFC7794].

* While RFC7794 Router-IDs are in fact IP addresses. OSPF Router-IDs are not
even if they happen to look like them, this is particularly germain with ospfv3
but it’s worth making the distinction.

4 -
5.1.1.  Operations

   Existing BGP and BGP-LS operational procedures apply.  No additional
   operation procedures are defined in this document.

* An informative or normative reference (probably to 7752 especially fault
mangement) is probably required.

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Wed, 9 May 2018 09:53:30 +0000

Hi Joel,

Many thanks for your review and please find responses inline below. I will update the draft with the same based on your feedback.

Thanks,
Ketan

-----Original Message-----
From: Joel Jaeggli <[email-masked]> 
Sent: 09 May 2018 12:16
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Opsdir early review of draft-ietf-idr-bgp-ls-segment-routing-ext-06

Reviewer: Joel Jaeggli
Review result: Has Nits

I have performed a requested early review on the behalf of the operations directorate of the current draft-ietf-idr-bgp-ls-segment-routing-ext-06.
Generally I think this document is good, I won't say ready, as this review is intended as an early review not a final one.

Some nits

1-
introduction

* BGP speakers are agnostic about the source of the information beyond that it was exported with certain properties from the rib of it’s neighbor.
[KT] I agree this is generally true in case of BGP. However, in this specific case of BGP-LS, the Node, Link and Prefix NLRIs actually contain the identifiers/descriptors which include the source of the information - as in the specific IGP node originating it. So would you agree that in this specific BGP-LS case the statement is valid?

2 -

* Unqualified use of the term northbound I find generally problematic, particularly in the case of a route reflector. Previously RFC 7752 manged to use the term in the title and then never again within the text.
[KT] Sure. I would remove the "northbound" term.

3-

    0                   1                   2                   3

   where:

      Length: 4 or 16.

* While RFC7794 Router-IDs are in fact IP addresses. OSPF Router-IDs are not even if they happen to look like them, this is particularly germain with ospfv3 but it’s worth making the distinction.
[KT] Agree. I would say "The semantic of the Source Router-ID TLV for ISIS is defined in [RFC7794]. For OSPF, the TLV carries the OSPF Router-ID of the originator of the prefix."

4 -
5.1.1.  Operations

* An informative or normative reference (probably to 7752 especially fault
mangement) is probably required.
[KT] Agree and I would specifically put the normative reference to RFC7752.

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 9 May 2018 14:35:31 +0000

> [KT] Agree. I would say "The semantic of the Source Router-ID TLV for ISIS is
> defined in [RFC7794]. For OSPF, the TLV carries the OSPF Router-ID of the
> originator of the prefix."

[Les:] Joel - your statement is technically correct - but Ketan's suggested text revision is repeating text that is present in the first paragraph of the section.

Since the point being made is in regards to the semantics of the value field would this be more clearly dealt with by  replacing

With 

//       4 or 16 octet Router-ID     //

??

   Les

---

From: "Aijun Wang" <[email-masked]>
Date: Thu, 10 May 2018 09:53:49 +0800

Hi, Joel:

Is there any IETF document to define the "IPv4/IPv6 Source Router ID" in OSPFv2/v3, for the similar scenarios that described in RFC7794?

Best Regards.

Aijun Wang
Network R&D and Operation Support Department
China Telecom Corporation Limited Beijing Research Institute,Beijing, China.

-----邮件原件-----
发件人: Joel Jaeggli [mailto:[email-masked]] 
发送时间: 2018年5月9日 14:46
收件人: [email-masked]
抄送: [email-masked]; [email-masked]; [email-masked]
主题: [Idr] Opsdir early review of draft-ietf-idr-bgp-ls-segment-routing-ext-06

Reviewer: Joel Jaeggli
Review result: Has Nits

Some nits

1-
introduction

2 -

3-

    0                   1                   2                   3

   where:

      Length: 4 or 16.

4 -
5.1.1.  Operations

_______________________________________________
Idr mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/idr

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Wed, 16 May 2018 04:26:41 +0000

Hi Joel,

A new version 07 of this draft has been just posted to address the comments from your review as discussed in the mail thread below.

https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-ls-segment-routing-ext/ 

Thanks,
Ketan

-----Original Message-----
From: Les Ginsberg (ginsberg) 
Sent: 09 May 2018 20:06
To: Ketan Talaulikar (ketant) <[email-masked]>; Joel Jaeggli <[email-masked]>; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: Opsdir early review of draft-ietf-idr-bgp-ls-segment-routing-ext-06

> * While RFC7794 Router-IDs are in fact IP addresses. OSPF Router-IDs 
> are not even if they happen to look like them, this is particularly 
> germain with ospfv3 but it’s worth making the distinction.
> [KT] Agree. I would say "The semantic of the Source Router-ID TLV for 
> ISIS is defined in [RFC7794]. For OSPF, the TLV carries the OSPF 
> Router-ID of the originator of the prefix."

With 

??

   Les