[Idr] Shepherd's report for draft-ietf-idr-bgpls-srv6-ext-05.txt

[Susan Hares <[e-mail]>]

Guarav, Ketan, Fils, Mach, Daniel, Bruno:  

 

First of all thank you for your hard work on refining
draft-ietf-idr-bgpls-srv6-ext-05.txt.  

I'm glad to have this draft in the SRv6 family. 

 

This shepherd report is a combination of my review and a review done by
Haibo Wang.   As you recall, I asked for SR-Reviews to review SR drafts in
addition to the document shepherds.   I've indicated Haibo's comments in my
review.  I appreciate his help in reviewing this IDR draft.  

 

I'm working this weekend in case you want me to review any changes before
the draft deadline on Monday. 

 

Cheers, Sue 

 

============

Issues are marked with levels: major or minor 

Resolution is marked as: Mandatory or recommended  

 

Issue #1: 

========

Location: Section 1:  paragraph 3, sentence

Issue:  Major

Change: Mandatory

 

Original Text: 

/BGP (I-D.ietf.bess-srv6-services)) has been extended to 

advertise some of these SRV6 SIDs and SRv6-related information./

 

Problem description: 

The reference to this bess draft means that you must support all the 

features within the draft. Specifically, if you are indicating support 

for the EVPN sections of this draft you are more likely to hit the 

issues described in section 4.9 of draft-ietf-idr-rfc7752bis-05.txt.   

If you wish to keep this text, you have two options: 

 

Option 1) Replace RFC7752 references with RFC7752bis and make appropriate
changes 

Or 

Option 2) Keep dependency on RFC7752 and change the last paragraph of
section 10. 

 

For option 2, I provide you with sample text change below.  

This text is just a example. 

 

Old Text/The extensions, specified in this document, do not introduce any
new 

configuration or monitoring aspects in BGP or BGP-LS other than discussed

in [RFC7752]./

 

New text:/The extensions, specified in this document, do not introduce any
new 

configuration, monitoring  or error handle aspects of BGP or BGP-LS other 

than those discussed in [RFC7752] and [RFC7752bis].  In some use cases

for topologies that might be used for draft-ietf-bess-srv6-services EVPN,

the error handling in [RFC7752bis] section 4.9 may be necessary to handle 

the combination of unreachable IGP nodes, BGP-LS with certain BGP Peer
topologies, 

and service requirements of VPN applications./  

 

===============================================================

Issue 2:  

Location: Section 3.1, page 6, figure 2

What changes:  Addition to field to clearly show Reserved fields

Issue: minor  

Change: Recommended 

Problem: Text unclear without reserve word 

 

Old text/

     0                   1

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

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

    | |O|                           |

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

/

New text/

     0                   1

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

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

    | |O|       Reserved            |

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

 

========================================= 

 

Issue 3:  

Location: Section 4.1, page 8, bullet beginning "Endpoint Behavior"

Issue: Major

Change: Mandatory 

 

Problem: section 9 is security considerations in 

[draft-ietf-spring-srv6-network-programming]

Perhaps you mean section 4 (SR EndPoint descriptions) or 

section 10.2 or 10.2.1 with the Initial registrations for

SRv6 Endpoint Behaviors.   

 

Old Text:

/End point Behavior: 2 octet field.  The Endpoint Behavior  code

Point for this SRV6 SID is defined in section 9.2 of

[I-D.ietf-spring-srv6-network-programming]

/

New Text /End point Behavior: 2 octet field.  The Endpoint Behavior  code

Point for this SRV6 SID is defined in section 10.2 of

[I-D.ietf-spring-srv6-network-programming]

/

 

 

=======================

Issue 4: 

Location: Section 4.2, figure 4, page 8

Type: minor 

Status: Recommended 

 

Old-Text/

     0 1 2 3 4 5 6 7

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

    |B|S|P|         |

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

/

 

New-Text/

     0 1 2 3 4 5 6 7

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

    |B|S|P| Reserved|

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

/

 

=============

Issue 5: 

Location: section 4.2, page 9, paragraph 1

Status: Major

Change: Mandatory to improve text  

 

Reviewers: [Haibo Wang and Susan Hares] 

 Old/Text chapter 4.2 SRv6 LAN End.X SID TLV.

 

   For a LAN interface, normally an IGP node only announces its

   adjacency to the IS-IS pseudo-node (or the equivalent OSPF DR).  The

   SRv6 LAN End.X SID TLV allows a node to announce SRv6 SID

   corresponding to behaviors like END.X

   [I-D.ietf-spring-srv6-network-programming] for its adjacencies to all

   other (i.e. non-DIS or non-DR) nodes attached to the LAN in a single

   instance of the BGP-LS Link NLRI.  Without this TLV, multiple BGP-LS

   Link NLRI would need to be originated for each additional adjacency

   in order to advertise the SRv6 End.X SID TLVs for these neighbor

   adjacencies.

/

Hares Comments: This paragraph is unclear.  It needs to be rewritten. 

[WangHaibo] suggests a way to approach this text:  

1.  I suggest to first describe the behavior of the LAN End.X SID
explicitly, 

such as "each LAN End.X SID is used to specify the 

cross-connect to one adjacency node attached to the LAN". 

Then describe how to encode the LAN End.X SID TLVs with 

the Link NLRI corresponding to the adjacency to DIS or DR.

==========

Issue 6: 

Location: section 4.2., p. 10, bullet beginning EndPoint Behavior

Issue: Major 

Change: Mandatory

Problem: Section 9 is in the security section. 

If you mean section 10.2, then the text change would be

Old Text/section 9.2 of [I-D.ietf-spring-srv6-network-programming]

New text/section 10.2 of [I-D.ietf-spring-srv6-network-programming]/

========

Issue 7: 

Location: section 4.2, figure 6 

Issue: Minor 

Problem: figure unclear without reserved words 

Change: Recommended 

Old text: /

 
     0 1 2 3 4 5 6 7
    +-+-+-+-+-+-+-+-+
    |B|S|P|         |
    +-+-+-+-+-+-+-+-+

/

New text:/

 
     0 1 2 3 4 5 6 7
    +-+-+-+-+-+-+-+-+
    |B|S|P| Reserved|
    +-+-+-+-+-+-+-+-+

========

Issue 8:  

Location: section 5.1, figure 8 

Issue: Minor 

Problem: figure unclear without reserved words 

Change: Recommended 

Old text: /

 
     0 1 2 3 4 5 6 7
    +-+-+-+-+-+-+-+-+
    |D|             |
    +-+-+-+-+-+-+-+-+

New text:/


     0 1 2 3 4 5 6 7
    +-+-+-+-+-+-+-+-+
    |D| Reserved    |
    +-+-+-+-+-+-+-+-+
 

======

Issue 9: 

Location: 2. SRv6 SID NLRI

Status: Major 

Changes: Some textual change is mandatory  

Problem: 

    [Wang Habio comments]

   Now the BGP EPE Peer Node info is advertised with SRv6 SID NLRI, it
cause[s] some disadvantages compared to SR-MPLE EPE.

   First, the number of NLRIs needed for SRv6 EPE may be more than MPLS EPE.
This is because the NLRI's key is SRv6 SID, but for one EPE Peer node, there
may be multiple SIDs, such as End.x with PSP, End.x with USD etc. 

   Second, with MPLS EPE, for a direct EBGP Peer, only one NLRI is needed to
advertise the link and its Peer node SID, link attributes.  But with the
current method for SRv6 EPE, at least two NLRIs are needed, one is the SRv6
SID NLRI for the Peer Node SID, the other is a Link NLRI with the End.X SID
(the SID value may be the same while need to be advertised in different
NLRIs) and link attributes..

  At current stage maybe it is not suitable to change the encoding, but I
suggest to give more detail description about the behavior of advertising
the SRv6 Peer node SID and the Peer adjacency SID with corresponding NLRIs
for a direct peer and for a peer established on loopback.  

 

[Hares] Solution possibilities: 

a) provide text in section 6 prior to NLRI format 

b) create section in manageability section providing more details

 

If have questions on this request for clarifying information, 

send email to me, Haibo, or the list. 

=========

Issue 10:  

Status: Major

Change: Mandatory 

Location: 7.1, bullet point that starts "Endpoint Behavior"

 

Old text/section 9.2 of [I-D.ietf-spring-srv6-network-programming]/

New text / section 10.2 of [I-D.ietf-spring-srv6-network-programming]/

========

Issue 11: page 17, Figure 13 

Problem: reserved fields

Type: Minor

Status: Recommended 

Old Text/ 

Location: 

     0 1 2 3 4 5 6 7

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

    |B|S|P|         |

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

 

            Figure 13: SRv6 BGP Peer End.X SID TLV Flags Format

 

/

NewText/ 

Location: 

     0 1 2 3 4 5 6 7

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

    |B|S|P| Reserved|

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

 

            Figure 13: SRv6 BGP Peer Node SID TLV Flags Format 

/

[Hares comment: Clearly specifying Reserved Fields in figure helps the
reader. 

 

[Wang Haibo comment:] 

   [comment]As Figure 13 is about the Flags of SRv6 BGP Peer Node SID TLV,
its name may be changed to SRv6 BGP Peer Node SID TLV Flags Format

 

==========

Location: Section 12:  Manageability section 

Praise: 

Thank you for mentioning the sematic or content checking is left to the
consumer of the BGP-LS information. 

============