> From: John G. Scudder [mailto:j...@juniper.net]  > Sent: Monday, March 13, 
> 2017 9:54 PM
> 
 > Thanks, Stefano.
 > 
 > Bruno, at your convenience can you confirm that you're satisfied with the 
 > resolution?

-11 addresses my comments.

Thank you John, Stefano.

> Looks
 > OK to me even though the changes don't precisely adhere to your suggestions 
 > ("Link NLRI
 > uses the Protocol-ID value" instead of "Link NLRI uses the BGP Protocol-ID 
 > value"). 

Indeed.
I still think that not indicating the Protocol-ID to use (either by its name 
"BGP" or its value "7")  is sub-optimal (or not useful), however, this text in 
section 6.1 is illustrative only. The normative text in §4 does state both the 
name and the code point. So this is good enough for me.

On a side note "(to be assigned by IANA)" seems wrong as the value has been 
assigned 
http://www.iana.org/assignments/bgp-ls-parameters/bgp-ls-parameters.xhtml  (And 
fixing this would also address the point above.)

--Bruno

> The
 > rfcdiff is 
 > https://tools.ietf.org/rfcdiff?url2=draft-ietf-idr-bgpls-segment-routing-epe-11.txt
 > 
 > --John
 > 
 > > On Mar 13, 2017, at 6:31 AM, Stefano Previdi (sprevidi) 
 > > <sprev...@cisco.com> wrote:
 > >
 > > John, Bruno,
 > >
 > > sorry for having missed that. I’ll resubmit right now. I integrated all 
 > > comments. Regarding
 > the missing "section 3.1" (referring to the isis draft), I replaced text 
 > with the reference to
 > draft-ietf-idr-bgp-ls-segment-routing-ext which defines the bgp-ls tlv for 
 > advertising the
 > SRGB. I gave this as an example. I also moved 
 > draft-ietf-spring-segment-routing into the
 > normative references section.
 > >
 > > Thanks.
 > >
 > > s.
 > >
 > >
 > >> On Mar 10, 2017, at 8:52 PM, John G.Scudder <j...@juniper.net> wrote:
 > >>
 > >> Hi Authors,
 > >>
 > >> I see that yesterday's -10 revision doesn't address Bruno's comments, 
 > >> below. Can you
 > please either update the document if you accept Bruno's suggestions, or 
 > otherwise discuss
 > them on the list? We can't declare the WGLC to be satisfactorily finished 
 > until this is
 > resolved.
 > >>
 > >> Thanks,
 > >>
 > >> --John
 > >>
 > >>> On Feb 16, 2017, at 11:50 AM, bruno.decra...@orange.com wrote:
 > >>>
 > >>> Hi,
 > >>>
 > >>> I’ve read the draft, please find below some minor comments:
 > >>>
 > >>> ---
 > >>> §4.3
 > >>> "      *  A 4 octet index defining the offset in the SID/Label space 
 > >>> advertised by this
 > router using the encodings defined in  Section 3.1."
 > >>>
 > >>> - Following the recent addition of the SRLB Label Space, I'd rather have 
 > >>> the text
 > explicitly refers to name of that Label space. e.g.
 > >>> OLD: SID/Label space
 > >>> NEW: SRGB
 > >>>
 > >>> - Which (SRGB) advertisement? I'm assuming the IGP one, but I guess 
 > >>> someone may
 > imagine using the BGP "Originator SRGB TLV". Then what if the node runs 
 > multiple IGP with
 > different SRGB configured?
 > >>>
 > >>> - Note that this document has no "Section 3.1". The text seems borrowed 
 > >>> from the IS-IS
 > SR draft, hence may be adding the name of this draft would just solve the 
 > point. (with a
 > normative reference to this IS-IS draft)
 > >>>
 > >>> ---
 > >>> OLD: The Link NLRI uses the new Protocol-ID value (to be assigned by 
 > >>> IANA)
 > >>> proposed NEW: The Link NLRI uses the BGP Protocol-ID (TBD1)
 > >>>
 > >>> (“new” may become unspecific 2 years from now)
 > >>>
 > >>> ---
 > >>> One could probably argue that [I-D.ietf-spring-segment-routing] should 
 > >>> be a normative
 > reference.
 > >>>
 > >>> Thanks,
 > >>> Regards,
 > >>> --Bruno
 > >>>
 > >>>
 > >>> From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Susan Hares
 > >>> Sent: Thursday, February 16, 2017 12:35 AM
 > >>> To: i...@ietf.org
 > >>> Cc: 'Alvaro Retana (aretana)'; spring@ietf.org
 > >>> Subject: [spring] IDR WG 2 week WG LC on 
 > >>> draft-ietf-idr-bgpls-segment-routing-epe -
 > (2/15/2017 to 3/1/2017)
 > >>>
 > >>> This begins a 2 week IDR WG last call on 
 > >>> draft-ietf-idr-bgpls-segment-routing-epe from
 > (2/15 to 3/1/2017)    There are two implementations describe on the wiki at:
 > >>> https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgpls-segment-routing-epe%20
 > >>>
 > >>> The two implementation are from  Cisco IOS-XR release 6.0.2 and Cisco 
 > >>> Nexus Switch
 > N9000/N3000 platforms running NX-OS 7.0(3)I1(1) or greater.   The authors 
 > will indicate on
 > the list and in the wiki the following information :
 > >>>
 > >>> 1)      Were these implementations separate implementations?
 > >>> 2)      What were the results of the interoperability tests?
 > >>>
 > >>> This work is linked to the draft-ietf-spring-segment-routing-central-epe 
 > >>> work in the
 > SPRING WG. Based on the two drafts, the WG should might consider:
 > >>> 1)      Is there need for this work in deployments in networks/
 > >>> 2)      Is this technically ready for publication?
 > >>> 3)      Does it fit with the spring informational draft?
 > >>>
 > >>> For the ease of reference the web references are below:
 > >>> https://datatracker.ietf.org/doc/draft-ietf-idr-bgpls-segment-routing-epe/
 > >>> https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-central-epe/
 > >>>
 > >>> Sue Hares
 > >>>
 > ______________________________________________________________________
 > ___________________________________________________
 > >>>
 > >>> Ce message et ses pieces jointes peuvent contenir des informations 
 > >>> confidentielles ou
 > privilegiees et ne doivent donc
 > >>> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez 
 > >>> recu ce message
 > par erreur, veuillez le signaler
 > >>> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
 > >>> electroniques
 > etant susceptibles d'alteration,
 > >>> Orange decline toute responsabilite si ce message a ete altere, deforme 
 > >>> ou falsifie.
 > Merci.
 > >>>
 > >>> This message and its attachments may contain confidential or privileged 
 > >>> information
 > that may be protected by law;
 > >>> they should not be distributed, used or copied without authorisation.
 > >>> If you have received this email in error, please notify the sender and 
 > >>> delete this
 > message and its attachments.
 > >>> As emails may be altered, Orange is not liable for messages that have 
 > >>> been modified,
 > changed or falsified.
 > >>> Thank you.
 > >>>
 > >>> _______________________________________________
 > >>> Idr mailing list
 > >>> i...@ietf.org
 > >>> https://www.ietf.org/mailman/listinfo/idr
 > >>
 > >


_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.

_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Reply via email to