Re: [Gen-art] [mpls] Review of draft-ietf-mpls-residence-time-12

[Hannes Gredler]

hi les,

we have taken turns long-time ago to advertise non-routing
related information which is only relevant to controllers
(l2bundles comes into mind ;-)).

while it would have been nice to get at least notice that
an IS-IS extension is being worked on (i mean prior to
IANA asking for expert review :-/ ) i see no reason why we
should hold this back. - we can argue perhaps whether it should
be part of GENAPP or ROUTERCAP TLVs, but i cannot see the
sky falling to advertise a non-routing related capability,
that does not change frequently.

/hannes

On 1/19/17 18:24, Les Ginsberg (ginsberg) wrote:
> John –
> 
>  
> 
> For me, this raises the age-old question of when it is/is not
> appropriate to use IGPs for flooding information.
> 
>  
> 
> This is clearly not TE information – you just happen to be using this in
> conjunction with MPLS – but it is a generic capability. I do not see the
> IGPs as the appropriate mechanism to flood generic interface
> capabilities. It also, as Acee has pointed out, results in flooding
> information to all nodes in the domain when only a few care about it.
> 
>  
> 
>Les
> 
>  
> 
> *From:*John E Drake [mailto:jdr...@juniper.net]
> *Sent:* Thursday, January 19, 2017 8:54 AM
> *To:* Acee Lindem (acee); Alexander Vainshtein; Greg Mirsky; Les
> Ginsberg (ginsberg)
> *Cc:* Robert Sparks; m...@ietf.org; gen-art@ietf.org;
> draft-ietf-mpls-residence-time@ietf.org; i...@ietf.org;
> isis-cha...@ietf.org; Abhay Roy (akr)
> *Subject:* RE: [mpls] Review of draft-ietf-mpls-residence-time-12
> 
>  
> 
> Acee,
> 
>  
> 
> Relying on an omniscient controller is a non-starter in general and in
> particular because the protocol by which it would learn each node’s RTM
> capabilities and distribute them to the other nodes is undefined. 
> Further, one of the ways by which an omniscient controller learns a
> node’s capabilities is by snooping the link/state database.
> 
>  
> 
> Yours Irrespectively,
> 
>  
> 
> John
> 
>  
> 
> *From:*Acee Lindem (acee) [mailto:a...@cisco.com]
> *Sent:* Thursday, January 19, 2017 11:47 AM
> *To:* John E Drake >;
> Alexander Vainshtein  >; Greg Mirsky
> >; Les Ginsberg
> (ginsberg) >
> *Cc:* Robert Sparks  >; m...@ietf.org ;
> gen-art@ietf.org ;
> draft-ietf-mpls-residence-time@ietf.org
> ; i...@ietf.org
> ; isis-cha...@ietf.org
> ; Abhay Roy (akr)  >
> *Subject:* Re: [mpls] Review of draft-ietf-mpls-residence-time-12
> 
>  
> 
> Hi John, 
> 
>  
> 
> *From: *John E Drake >
> *Date: *Thursday, January 19, 2017 at 10:43 AM
> *To: *Acee Lindem >, Alexander
> Vainshtein  >, Greg Mirsky
> >, "Les Ginsberg
> (ginsberg)" >
> *Cc: *Robert Sparks  >, "m...@ietf.org "
> >, "gen-art@ietf.org
> " >,
> "draft-ietf-mpls-residence-time@ietf.org
> "
>  >, "i...@ietf.org
> " >,
> "isis-cha...@ietf.org "
> >, "Abhay Roy (akr)"
> >
> *Subject: *RE: [mpls] Review of draft-ietf-mpls-residence-time-12
> 
>  
> 
> Acee,
> 
>  
> 
> We discussed all of this with you over a year ago and used your
> guidance in adding the indication of RTM capability to OSPF.
> 
>  
> 
> I’m sorry but I focused mainly on the OSPF protocol aspects then and
> didn’t question the use case. This question came up in the IS-IS WG
> discussions. 
> 
>  
> 
> Thanks,
> 
> Acee
> 
>  
> 
>  
> 
> Yours Irrespectively,
> 
>  
> 
> John
> 
>  
> 
> *From:*Acee Lindem (acee) [mailto:a...@cisco.com]
> *Sent:* Thursday, January 19, 2017 11:38 AM
> *To:* Alexander Vainshtein  >; Greg Mirsky
> >; Les Ginsberg
> (ginsberg) >
> *Cc:* Robert Sparks 

Re: [Gen-art] [mpls] Review of draft-ietf-mpls-residence-time-12

[Acee Lindem (acee)]

Hi Stewart,

So you are saying in this use case some element would create a path composed 
solely of nodes supporting RTM?

Thanks,
Acee

From: Stewart Bryant >
Date: Thursday, January 19, 2017 at 5:04 PM
To: Uma Chunduri >, 
"Les Ginsberg (ginsberg)" >, John 
E Drake >, Acee Lindem 
>, Alexander Vainshtein 
>, 
Greg Mirsky >
Cc: "Abhay Roy (akr)" >, 
"m...@ietf.org" >, 
"isis-cha...@ietf.org" 
>, 
"gen-art@ietf.org" 
>, 
"draft-ietf-mpls-residence-time@ietf.org"
 
>,
 Robert Sparks >, 
"i...@ietf.org" >
Subject: Re: [mpls] Review of draft-ietf-mpls-residence-time-12


Well one scenario is that you would use SR to create the synchronization path, 
in which case you would need it to be in the IGP and flooded.

Stewart

On 19/01/2017 19:40, Uma Chunduri wrote:
I support advertising this in IGP.


>This is clearly not TE information –..
>I do not see the IGPs as the appropriate mechanism to flood generic interface 
>capabilities

We have instances where both the above are not met and we flooded information.
https://tools.ietf.org/html/rfc7883 (Les, you co-authored the same!!)
https://tools.ietf.org/html/rfc7880

--
Uma C.

From: mpls [mailto:mpls-boun...@ietf.org] On Behalf Of Les Ginsberg (ginsberg)
Sent: Thursday, January 19, 2017 9:25 AM
To: John E Drake ; Acee Lindem 
(acee) ; Alexander Vainshtein 
; 
Greg Mirsky 
Cc: Abhay Roy (akr) ; 
m...@ietf.org; 
isis-cha...@ietf.org; 
gen-art@ietf.org; 
draft-ietf-mpls-residence-time@ietf.org;
 Robert Sparks ; 
i...@ietf.org
Subject: Re: [mpls] Review of draft-ietf-mpls-residence-time-12

John –

For me, this raises the age-old question of when it is/is not appropriate to 
use IGPs for flooding information.

This is clearly not TE information – you just happen to be using this in 
conjunction with MPLS – but it is a generic capability. I do not see the IGPs 
as the appropriate mechanism to flood generic interface capabilities. It also, 
as Acee has pointed out, results in flooding information to all nodes in the 
domain when only a few care about it.

   Les

From: John E Drake [mailto:jdr...@juniper.net]
Sent: Thursday, January 19, 2017 8:54 AM
To: Acee Lindem (acee); Alexander Vainshtein; Greg Mirsky; Les Ginsberg 
(ginsberg)
Cc: Robert Sparks; m...@ietf.org; 
gen-art@ietf.org; 
draft-ietf-mpls-residence-time@ietf.org;
 i...@ietf.org; 
isis-cha...@ietf.org; Abhay Roy (akr)
Subject: RE: [mpls] Review of draft-ietf-mpls-residence-time-12

Acee,

Relying on an omniscient controller is a non-starter in general and in 
particular because the protocol by which it would learn each node’s RTM 
capabilities and distribute them to the other nodes is undefined.  Further, one 
of the ways by which an omniscient controller learns a node’s capabilities is 
by snooping the link/state database.

Yours Irrespectively,

John

From: Acee Lindem (acee) [mailto:a...@cisco.com]
Sent: Thursday, January 19, 2017 11:47 AM
To: John E Drake >; Alexander 
Vainshtein 
>; 
Greg Mirsky >; Les Ginsberg 
(ginsberg) >
Cc: Robert Sparks >; 
m...@ietf.org; gen-art@ietf.org; 
draft-ietf-mpls-residence-time@ietf.org;
 i...@ietf.org; 

Re: [Gen-art] [mpls] Review of draft-ietf-mpls-residence-time-12

[Stewart Bryant]

Well one scenario is that you would use SR to create the synchronization 
path, in which case you would need it to be in the IGP and flooded.


Stewart


On 19/01/2017 19:40, Uma Chunduri wrote:


I support advertising this in IGP.

>This is clearly not TE information –..

>I do not see the IGPs as the appropriate mechanism to flood generic 
interface capabilities


We have instances where both the above are not met and we flooded 
information.


https://tools.ietf.org/html/rfc7883(Les, you co-authored the same!!)

https://tools.ietf.org/html/rfc7880

--

Uma C.

*From:*mpls [mailto:mpls-boun...@ietf.org] *On Behalf Of *Les Ginsberg 
(ginsberg)

*Sent:* Thursday, January 19, 2017 9:25 AM
*To:* John E Drake ; Acee Lindem (acee) 
; Alexander Vainshtein 
; Greg Mirsky 
*Cc:* Abhay Roy (akr) ; m...@ietf.org; 
isis-cha...@ietf.org; gen-art@ietf.org; 
draft-ietf-mpls-residence-time@ietf.org; Robert Sparks 
; i...@ietf.org

*Subject:* Re: [mpls] Review of draft-ietf-mpls-residence-time-12

John –

For me, this raises the age-old question of when it is/is not 
appropriate to use IGPs for flooding information.


This is clearly not TE information – you just happen to be using this 
in conjunction with MPLS – but it is a generic capability. I do not 
see the IGPs as the appropriate mechanism to flood generic interface 
capabilities. It also, as Acee has pointed out, results in flooding 
information to all nodes in the domain when only a few care about it.


Les

*From:*John E Drake [mailto:jdr...@juniper.net]
*Sent:* Thursday, January 19, 2017 8:54 AM
*To:* Acee Lindem (acee); Alexander Vainshtein; Greg Mirsky; Les 
Ginsberg (ginsberg)
*Cc:* Robert Sparks; m...@ietf.org ; 
gen-art@ietf.org ; 
draft-ietf-mpls-residence-time@ietf.org 
; i...@ietf.org 
; isis-cha...@ietf.org 
; Abhay Roy (akr)

*Subject:* RE: [mpls] Review of draft-ietf-mpls-residence-time-12

Acee,

Relying on an omniscient controller is a non-starter in general and in 
particular because the protocol by which it would learn each node’s 
RTM capabilities and distribute them to the other nodes is undefined.  
Further, one of the ways by which an omniscient controller learns a 
node’s capabilities is by snooping the link/state database.


Yours Irrespectively,

John

*From:*Acee Lindem (acee) [mailto:a...@cisco.com]
*Sent:* Thursday, January 19, 2017 11:47 AM
*To:* John E Drake >; 
Alexander Vainshtein >; Greg Mirsky 
>; Les Ginsberg 
(ginsberg) >
*Cc:* Robert Sparks >; m...@ietf.org ; 
gen-art@ietf.org ; 
draft-ietf-mpls-residence-time@ietf.org 
; i...@ietf.org 
; isis-cha...@ietf.org 
; Abhay Roy (akr) >

*Subject:* Re: [mpls] Review of draft-ietf-mpls-residence-time-12

Hi John,

*From: *John E Drake >
*Date: *Thursday, January 19, 2017 at 10:43 AM
*To: *Acee Lindem >, Alexander 
Vainshtein >, Greg Mirsky 
>, "Les Ginsberg 
(ginsberg)" >
*Cc: *Robert Sparks >, "m...@ietf.org " 
>, "gen-art@ietf.org 
" >, 
"draft-ietf-mpls-residence-time@ietf.org 
" 
>, "i...@ietf.org 
" >, 
"isis-cha...@ietf.org " 
>, "Abhay Roy 
(akr)" >

*Subject: *RE: [mpls] Review of draft-ietf-mpls-residence-time-12

Acee,

We discussed all of this with you over a year ago and used your
guidance in adding the indication of RTM capability to OSPF.

I’m sorry but I focused mainly on the OSPF protocol aspects then and 
didn’t question the use case. This question came up in the IS-IS WG 
discussions.


Thanks,

Acee

Yours Irrespectively,

John

Re: [Gen-art] [mpls] Review of draft-ietf-mpls-residence-time-12

[Les Ginsberg (ginsberg)]

John -

From: John E Drake [mailto:jdr...@juniper.net]
Sent: Thursday, January 19, 2017 2:04 PM
To: Les Ginsberg (ginsberg); Acee Lindem (acee); Alexander Vainshtein; Greg 
Mirsky
Cc: Robert Sparks; m...@ietf.org; gen-art@ietf.org; 
draft-ietf-mpls-residence-time@ietf.org; i...@ietf.org; 
isis-cha...@ietf.org; Abhay Roy (akr)
Subject: RE: [mpls] Review of draft-ietf-mpls-residence-time-12

Les,

Shall we go with a sub-TLV of TLV 22
[Les:] If that is the direction the WG wants to go I am OK with it - but I do 
think this proposal should be sent to the IS-IS WG for comment as well.

and promise to never ever to do this again?

[Les:] LOL...sure!

   Les

Btw, I am extremely sorry that we didn't engage with the IS-IS community and I 
don't know why we didn't.  As I said in an earlier email, we worked pretty 
extensively with Acee on the OSPF aspects and with Lou Berger on the RSVP-TE 
aspects and received a lot of useful feedback from both of them.

Yours Irrespectively,

John

From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com]
Sent: Thursday, January 19, 2017 4:55 PM
To: John E Drake >; Acee Lindem 
(acee) >; Alexander Vainshtein 
>; 
Greg Mirsky >
Cc: Robert Sparks >; 
m...@ietf.org; gen-art@ietf.org; 
draft-ietf-mpls-residence-time@ietf.org;
 i...@ietf.org; 
isis-cha...@ietf.org; Abhay Roy (akr) 
>
Subject: RE: [mpls] Review of draft-ietf-mpls-residence-time-12

John -

From: John E Drake [mailto:jdr...@juniper.net]
Sent: Thursday, January 19, 2017 1:19 PM
To: Les Ginsberg (ginsberg); Acee Lindem (acee); Alexander Vainshtein; Greg 
Mirsky
Cc: Robert Sparks; m...@ietf.org; 
gen-art@ietf.org; 
draft-ietf-mpls-residence-time@ietf.org;
 i...@ietf.org; 
isis-cha...@ietf.org; Abhay Roy (akr)
Subject: RE: [mpls] Review of draft-ietf-mpls-residence-time-12

Les,

I understand and I have made the same argument in other contexts and with 
similar results ("... and your point is?").
[Les:] Nice to know I am not completely alone.:-)

It would be good if the authors/WG at least considered a non-IGP approach.
However, if the IGP approach is to be taken, the GENINFO definition currently 
in the draft is unacceptable for reasons I have previously given. So this 
should be reworked - probably to use a sub-TLV of TLV 22 et al.
The other alternative would be to define a GENINFO application that could 
support advertising many interface attributes - I don't think anyone wants to 
go in that direction - certainly not me.

   Les


However, as I indicated in my previous email, RTM would be used as part of the 
network infrastructure as a way to provide time synchronization between the 
nodes in the network, so I would consider it similar to the S-BFDs that Uma and 
you were discussing.

Yours Irrespectively,

John

From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com]
Sent: Thursday, January 19, 2017 4:09 PM
To: John E Drake >; Acee Lindem 
(acee) >; Alexander Vainshtein 
>; 
Greg Mirsky >
Cc: Robert Sparks >; 
m...@ietf.org; gen-art@ietf.org; 
draft-ietf-mpls-residence-time@ietf.org;
 i...@ietf.org; 
isis-cha...@ietf.org; Abhay Roy (akr) 
>
Subject: RE: [mpls] Review of draft-ietf-mpls-residence-time-12

John -

The text you have excerpted below was trying to say two things:

1)If you want to advertise this in the IGPs the OSPF style proposal is much 
better from an implementation standpoint than the IS-IS GENAPP proposal

2)There is a larger question as to whether we should be using the IGPs for this 
at all

Statement #1 should not be interpreted to imply that I am advocating using the 
IGPs. :)

That said, we "ALWAYS" end up choosing using the IGPs to do this sort of thing 
- not because it is the "RIGHT" thing to do architecturally - but because it is 
so convenient.

I am just asking for folks to pause and think about this a bit more from an 
architectural perspective.

   Les


From: John E Drake [mailto:jdr...@juniper.net]
Sent: Thursday, January 19, 2017 12:20 PM

Re: [Gen-art] [mpls] Review of draft-ietf-mpls-residence-time-12

[Greg Mirsky]

Hi Les,
thank you for your thoughtful consideration and the most helpful
suggestion. I'll prepare update accordingly and share with you and the
IS-IS community.
And, as John expressed, sorry that missed to reach to IS-IS experts in the
first place.

Regards, Greg

On Thu, Jan 19, 2017 at 2:04 PM, John E Drake  wrote:

> Les,
>
>
>
> Shall we go with a sub-TLV of TLV 22 and promise to never ever to do this
> again?
>
>
>
> Btw, I am extremely sorry that we didn’t engage with the IS-IS community
> and I don’t know why we didn’t.  As I said in an earlier email, we worked
> pretty extensively with Acee on the OSPF aspects and with Lou Berger on the
> RSVP-TE aspects and received a lot of useful feedback from both of them.
>
>
>
> Yours Irrespectively,
>
>
>
> John
>
>
>
> *From:* Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com]
> *Sent:* Thursday, January 19, 2017 4:55 PM
>
> *To:* John E Drake ; Acee Lindem (acee) <
> a...@cisco.com>; Alexander Vainshtein ;
> Greg Mirsky 
> *Cc:* Robert Sparks ; m...@ietf.org;
> gen-art@ietf.org; draft-ietf-mpls-residence-time@ietf.org;
> i...@ietf.org; isis-cha...@ietf.org; Abhay Roy (akr) 
> *Subject:* RE: [mpls] Review of draft-ietf-mpls-residence-time-12
>
>
>
> John -
>
>
>
> *From:* John E Drake [mailto:jdr...@juniper.net ]
> *Sent:* Thursday, January 19, 2017 1:19 PM
> *To:* Les Ginsberg (ginsberg); Acee Lindem (acee); Alexander Vainshtein;
> Greg Mirsky
> *Cc:* Robert Sparks; m...@ietf.org; gen-art@ietf.org;
> draft-ietf-mpls-residence-time@ietf.org; i...@ietf.org;
> isis-cha...@ietf.org; Abhay Roy (akr)
> *Subject:* RE: [mpls] Review of draft-ietf-mpls-residence-time-12
>
>
>
> Les,
>
>
>
> I understand and I have made the same argument in other contexts and with
> similar results (“… and your point is?”).
>
> *[Les:] Nice to know I am not completely alone.:-)*
>
>
>
> *It would be good if the authors/WG at least considered a non-IGP
> approach.*
>
> *However, if the IGP approach is to be taken, the GENINFO definition
> currently in the draft is unacceptable for reasons I have previously given.
> So this should be reworked – probably to use a sub-TLV of TLV 22 et al.*
>
> *The other alternative would be to define a GENINFO application that could
> support advertising many interface attributes – I don’t think anyone wants
> to go in that direction – certainly not me.*
>
>
>
> *   Les*
>
>
>
>
>
> However, as I indicated in my previous email, RTM would be used as part of
> the network infrastructure as a way to provide time synchronization between
> the nodes in the network, so I would consider it similar to the S-BFDs that
> Uma and you were discussing.
>
>
>
> Yours Irrespectively,
>
>
>
> John
>
>
>
> *From:* Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com
> ]
> *Sent:* Thursday, January 19, 2017 4:09 PM
> *To:* John E Drake ; Acee Lindem (acee) <
> a...@cisco.com>; Alexander Vainshtein ;
> Greg Mirsky 
> *Cc:* Robert Sparks ; m...@ietf.org;
> gen-art@ietf.org; draft-ietf-mpls-residence-time@ietf.org;
> i...@ietf.org; isis-cha...@ietf.org; Abhay Roy (akr) 
> *Subject:* RE: [mpls] Review of draft-ietf-mpls-residence-time-12
>
>
>
> John –
>
>
>
> The text you have excerpted below was trying to say two things:
>
>
>
> 1)If you want to advertise this in the IGPs the OSPF style proposal is
> much better from an implementation standpoint than the IS-IS GENAPP proposal
>
>
>
> 2)There is a larger question as to whether we should be using the IGPs for
> this at all
>
>
>
> Statement #1 should not be interpreted to imply that I am advocating using
> the IGPs. J
>
>
>
> That said, we “ALWAYS” end up choosing using the IGPs to do this sort of
> thing – not because it is the “RIGHT” thing to do architecturally – but
> because it is so convenient.
>
>
>
> I am just asking for folks to pause and think about this a bit more from
> an architectural perspective.
>
>
>
>Les
>
>
>
>
>
> *From:* John E Drake [mailto:jdr...@juniper.net ]
> *Sent:* Thursday, January 19, 2017 12:20 PM
> *To:* Les Ginsberg (ginsberg); Acee Lindem (acee); Alexander Vainshtein;
> Greg Mirsky
> *Cc:* Robert Sparks; m...@ietf.org; gen-art@ietf.org;
> draft-ietf-mpls-residence-time@ietf.org; i...@ietf.org;
> isis-cha...@ietf.org; Abhay Roy (akr)
> *Subject:* RE: [mpls] Review of draft-ietf-mpls-residence-time-12
>
>
>
> Les,
>
>
>
> Comments inline.
>
>
>
> Yours Irrespectively,
>
>
>
> John
>
>
>
> *From:* Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com
> ]
> *Sent:* Thursday, January 19, 2017 12:25 PM
> *To:* John E Drake ; Acee Lindem (acee) <
> a...@cisco.com>; Alexander Vainshtein ;
> Greg Mirsky 

[Gen-art] Review Assignments

[Jean Mahoney]

Hi all,

The following reviewers have assignments:

For telechat 2017-02-02

Reviewer   Type  LC end Draft
Francis Dupont Telechat  2017-01-12 
draft-ietf-softwire-dslite-multicast-16 *
Roni Even  Telechat  2017-01-12 
draft-ietf-softwire-multicast-prefix-option-12 *
Joel Halpern   Telechat  None   draft-ietf-oauth-jwsreq-09
Christer Holmberg  Last Call 2017-01-19 
draft-ietf-dhc-dhcpv6-failover-protocol-03
Pete Resnick   Last Call 2017-01-31 draft-ietf-ipsecme-rfc4307bis-15
Robert Sparks  Telechat  2017-01-06 
draft-ietf-kitten-krb-auth-indicator-06 *
Robert Sparks  Last Call 2017-01-24 draft-ietf-geojson-text-sequence-03
Dale WorleyTelechat  2017-01-17 
draft-ietf-teas-gmpls-resource-sharing-proc-07 *

For telechat 2017-02-16

Reviewer   Type  LC end Draft
Christer Holmberg  Telechat  2017-01-16 draft-ietf-dnsop-edns-key-tag-04 *
Orit Levin Last Call 2017-01-31 draft-ietf-sidr-delta-protocol-05
Pete Resnick   Last Call 2017-01-31 
draft-ietf-ccamp-flexible-grid-ospf-ext-07
Lucy Yong  Last Call 2017-01-30 
draft-ietf-sidr-rpki-rtr-rfc6810-bis-08

Last calls:

Reviewer   Type  LC end Draft
Stewart Bryant Last Call 2017-01-30 draft-ietf-lamps-eai-addresses-05
Brian CarpenterLast Call 2017-02-15 draft-bradner-rfc3979bis-10 *
Elwyn Davies   Last Call 2017-01-26 draft-ietf-mmusic-4572-update-11
Francis Dupont Last Call 2017-02-14 draft-freytag-lager-variant-rules-02
Francis Dupont Last Call 2017-01-23 draft-ietf-bmwg-ipv6-nd-04
Fernando Gont  Last Call 2017-01-23 draft-ietf-dime-agent-overload-08

* Other revision previously reviewed
** This revision already reviewed

Next in the reviewer rotation:

  Robert Sparks
  Dale Worley
  Peter Yee
  Lucy Yong
  Stewart Bryant
  Brian Carpenter
  Elwyn Davies
  Ralph Droms
  Francis Dupont
  Roni Even

The LC and Telechat review templates are included below:
---

-- Begin LC Template --
I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

.

Document:
Reviewer:
Review Date:
IETF LC End Date:
IESG Telechat date: (if known)

Summary:

Major issues:

Minor issues:

Nits/editorial comments: 

-- End LC Template --

-- Begin Telechat Template --
I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please wait for direction from your
document shepherd or AD before posting a new version of the draft.

For more information, please see the FAQ at

.

Document:
Reviewer:
Review Date:
IETF LC End Date:
IESG Telechat date: (if known)

Summary:

Major issues:

Minor issues:

Nits/editorial comments:

-- End Telechat Template --


___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] [mpls] Review of draft-ietf-mpls-residence-time-12

[John E Drake]

Les,

Shall we go with a sub-TLV of TLV 22 and promise to never ever to do this again?

Btw, I am extremely sorry that we didn't engage with the IS-IS community and I 
don't know why we didn't.  As I said in an earlier email, we worked pretty 
extensively with Acee on the OSPF aspects and with Lou Berger on the RSVP-TE 
aspects and received a lot of useful feedback from both of them.

Yours Irrespectively,

John

From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com]
Sent: Thursday, January 19, 2017 4:55 PM
To: John E Drake ; Acee Lindem (acee) ; 
Alexander Vainshtein ; Greg Mirsky 

Cc: Robert Sparks ; m...@ietf.org; gen-art@ietf.org; 
draft-ietf-mpls-residence-time@ietf.org; i...@ietf.org; 
isis-cha...@ietf.org; Abhay Roy (akr) 
Subject: RE: [mpls] Review of draft-ietf-mpls-residence-time-12

John -

From: John E Drake [mailto:jdr...@juniper.net]
Sent: Thursday, January 19, 2017 1:19 PM
To: Les Ginsberg (ginsberg); Acee Lindem (acee); Alexander Vainshtein; Greg 
Mirsky
Cc: Robert Sparks; m...@ietf.org; 
gen-art@ietf.org; 
draft-ietf-mpls-residence-time@ietf.org;
 i...@ietf.org; 
isis-cha...@ietf.org; Abhay Roy (akr)
Subject: RE: [mpls] Review of draft-ietf-mpls-residence-time-12

Les,

I understand and I have made the same argument in other contexts and with 
similar results ("... and your point is?").
[Les:] Nice to know I am not completely alone.:-)

It would be good if the authors/WG at least considered a non-IGP approach.
However, if the IGP approach is to be taken, the GENINFO definition currently 
in the draft is unacceptable for reasons I have previously given. So this 
should be reworked - probably to use a sub-TLV of TLV 22 et al.
The other alternative would be to define a GENINFO application that could 
support advertising many interface attributes - I don't think anyone wants to 
go in that direction - certainly not me.

   Les


However, as I indicated in my previous email, RTM would be used as part of the 
network infrastructure as a way to provide time synchronization between the 
nodes in the network, so I would consider it similar to the S-BFDs that Uma and 
you were discussing.

Yours Irrespectively,

John

From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com]
Sent: Thursday, January 19, 2017 4:09 PM
To: John E Drake >; Acee Lindem 
(acee) >; Alexander Vainshtein 
>; 
Greg Mirsky >
Cc: Robert Sparks >; 
m...@ietf.org; gen-art@ietf.org; 
draft-ietf-mpls-residence-time@ietf.org;
 i...@ietf.org; 
isis-cha...@ietf.org; Abhay Roy (akr) 
>
Subject: RE: [mpls] Review of draft-ietf-mpls-residence-time-12

John -

The text you have excerpted below was trying to say two things:

1)If you want to advertise this in the IGPs the OSPF style proposal is much 
better from an implementation standpoint than the IS-IS GENAPP proposal

2)There is a larger question as to whether we should be using the IGPs for this 
at all

Statement #1 should not be interpreted to imply that I am advocating using the 
IGPs. :)

That said, we "ALWAYS" end up choosing using the IGPs to do this sort of thing 
- not because it is the "RIGHT" thing to do architecturally - but because it is 
so convenient.

I am just asking for folks to pause and think about this a bit more from an 
architectural perspective.

   Les


From: John E Drake [mailto:jdr...@juniper.net]
Sent: Thursday, January 19, 2017 12:20 PM
To: Les Ginsberg (ginsberg); Acee Lindem (acee); Alexander Vainshtein; Greg 
Mirsky
Cc: Robert Sparks; m...@ietf.org; 
gen-art@ietf.org; 
draft-ietf-mpls-residence-time@ietf.org;
 i...@ietf.org; 
isis-cha...@ietf.org; Abhay Roy (akr)
Subject: RE: [mpls] Review of draft-ietf-mpls-residence-time-12

Les,

Comments inline.

Yours Irrespectively,

John

From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com]
Sent: Thursday, January 19, 2017 12:25 PM
To: John E Drake >; Acee Lindem 
(acee) >; Alexander Vainshtein 
>; 
Greg Mirsky >
Cc: 

Re: [Gen-art] [mpls] Review of draft-ietf-mpls-residence-time-12

[Les Ginsberg (ginsberg)]

Eric -

From: Eric Gray [mailto:eric.g...@ericsson.com]
Sent: Thursday, January 19, 2017 12:32 PM
To: Les Ginsberg (ginsberg); Uma Chunduri; John E Drake; Acee Lindem (acee); 
Alexander Vainshtein; Greg Mirsky
Cc: m...@ietf.org; i...@ietf.org; isis-cha...@ietf.org; gen-art@ietf.org; 
draft-ietf-mpls-residence-time@ietf.org; Abhay Roy (akr); Robert Sparks
Subject: RE: [mpls] Review of draft-ietf-mpls-residence-time-12

Les,

It's nice to have a good discussion about technical aspects of 
a proposed standard, even late in the game.
[Les:] There is context you may not have.
"I" only became aware of this because - as one of the Designated Experts for 
IS-IS Registries - I was asked by IANA to approve the allocation of codepoints 
for the GENINFO proposal in the draft.
It would have been better had the IGP WGs been apprised of this draft and asked 
for feedback earlier in the process - but AFAIK that did not happen. This is a 
bit strange given that the draft authors include folks with long experience in 
MPLS/IGP interworking - but I am not trying to place blame. For whatever reason 
this did not happen.

I do appreciate how late in the game this discussion is - but as I do not 
personally follow MPLS drafts in general I was unaware of this draft until the 
IANA request was sent.
Too late to fix this now - but something to be considered in the future when 
there are IGP extensions involved in MPLS Drafts.

But I have some difficulty is seeing how this usage is "clearly 
not TE information."
[Les:] The packet timing capability which you are asking IGPs to advertise is a 
generic capability which could be used for many purposes. The fact that you are 
applying it to MPLS LSPs does not make the capability an MPLS/TE related 
capability.
   Les

This information should allow the head-end of an LSP to select a path based on 
desirable interface capabilities.  For the purposes of accurate time 
information, the best path may not also be the shortest path.  Is this not 
exactly what traffic engineering is about?

As far as extending this argument to the ability to advertise additional link 
capabilities, I can easily imagine scenarios where that would make sense.  But 
nobody is suggesting that every LSR (or router for that matter) either must 
have this capability for every scenario, or that - having the capability - it 
would need to be turned on.

If there is an application or use-case out there that might require advertising 
every conceivable interface capability, then vendors will want to take a look 
at the size of the opportunity represented by that and make a decision as to 
whether or not to support this.

--
Eric

From: mpls [mailto:mpls-boun...@ietf.org] On Behalf Of Les Ginsberg (ginsberg)
Sent: Thursday, January 19, 2017 3:11 PM
To: Uma Chunduri >; 
John E Drake >; Acee Lindem 
(acee) >; Alexander Vainshtein 
>; 
Greg Mirsky >
Cc: m...@ietf.org; i...@ietf.org; 
isis-cha...@ietf.org; 
gen-art@ietf.org; 
draft-ietf-mpls-residence-time@ietf.org;
 Abhay Roy (akr) >; Robert Sparks 
>
Subject: Re: [mpls] Review of draft-ietf-mpls-residence-time-12

Uma -

I readily admit S-BFD descriptors are - strictly speaking - a violation of the 
"non-routing info" policy - this was publicly acknowledged at the time the 
drafts were written. The exception was justified on the basis that:

  o IGPs are BFD clients
  o The S-BFD discriminator information is unique and extremely modest in size

What we have here is a proposal to start advertising non-routing related 
interface attribute information. There is nothing special or unique about RTM - 
it is simply one of many interface attributes which are generic in nature. 
Having agreed to advertise RTM in the IGPs, how would you then determine what 
other interface attributes should/should not be advertised by the IGPs? Take a 
look at your favorite vendors box and see how many interface attributes can be 
configured.
It is also concerning that - when using the IGPs - we flood information which 
must be stored on every node even though the use case for it is limited to a 
much smaller subset.

I think we can and should be smarter in this regard - and given the extensive 
work being done to enhance manageability I would like to see us benefit from 
this.

The authors of draft-ietf-mpls-residence-time clearly had some thoughts in this 
regard - which is why they proposed to use RFC 6823 (GENAPP) in IS-IS to 
advertise the information -but the 

Re: [Gen-art] [mpls] Review of draft-ietf-mpls-residence-time-12

[Les Ginsberg (ginsberg)]

John -

From: John E Drake [mailto:jdr...@juniper.net]
Sent: Thursday, January 19, 2017 1:19 PM
To: Les Ginsberg (ginsberg); Acee Lindem (acee); Alexander Vainshtein; Greg 
Mirsky
Cc: Robert Sparks; m...@ietf.org; gen-art@ietf.org; 
draft-ietf-mpls-residence-time@ietf.org; i...@ietf.org; 
isis-cha...@ietf.org; Abhay Roy (akr)
Subject: RE: [mpls] Review of draft-ietf-mpls-residence-time-12

Les,

I understand and I have made the same argument in other contexts and with 
similar results ("... and your point is?").
[Les:] Nice to know I am not completely alone.:-)

It would be good if the authors/WG at least considered a non-IGP approach.
However, if the IGP approach is to be taken, the GENINFO definition currently 
in the draft is unacceptable for reasons I have previously given. So this 
should be reworked - probably to use a sub-TLV of TLV 22 et al.
The other alternative would be to define a GENINFO application that could 
support advertising many interface attributes - I don't think anyone wants to 
go in that direction - certainly not me.

   Les


However, as I indicated in my previous email, RTM would be used as part of the 
network infrastructure as a way to provide time synchronization between the 
nodes in the network, so I would consider it similar to the S-BFDs that Uma and 
you were discussing.

Yours Irrespectively,

John

From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com]
Sent: Thursday, January 19, 2017 4:09 PM
To: John E Drake >; Acee Lindem 
(acee) >; Alexander Vainshtein 
>; 
Greg Mirsky >
Cc: Robert Sparks >; 
m...@ietf.org; gen-art@ietf.org; 
draft-ietf-mpls-residence-time@ietf.org;
 i...@ietf.org; 
isis-cha...@ietf.org; Abhay Roy (akr) 
>
Subject: RE: [mpls] Review of draft-ietf-mpls-residence-time-12

John -

The text you have excerpted below was trying to say two things:

1)If you want to advertise this in the IGPs the OSPF style proposal is much 
better from an implementation standpoint than the IS-IS GENAPP proposal

2)There is a larger question as to whether we should be using the IGPs for this 
at all

Statement #1 should not be interpreted to imply that I am advocating using the 
IGPs. :)

That said, we "ALWAYS" end up choosing using the IGPs to do this sort of thing 
- not because it is the "RIGHT" thing to do architecturally - but because it is 
so convenient.

I am just asking for folks to pause and think about this a bit more from an 
architectural perspective.

   Les


From: John E Drake [mailto:jdr...@juniper.net]
Sent: Thursday, January 19, 2017 12:20 PM
To: Les Ginsberg (ginsberg); Acee Lindem (acee); Alexander Vainshtein; Greg 
Mirsky
Cc: Robert Sparks; m...@ietf.org; 
gen-art@ietf.org; 
draft-ietf-mpls-residence-time@ietf.org;
 i...@ietf.org; 
isis-cha...@ietf.org; Abhay Roy (akr)
Subject: RE: [mpls] Review of draft-ietf-mpls-residence-time-12

Les,

Comments inline.

Yours Irrespectively,

John

From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com]
Sent: Thursday, January 19, 2017 12:25 PM
To: John E Drake >; Acee Lindem 
(acee) >; Alexander Vainshtein 
>; 
Greg Mirsky >
Cc: Robert Sparks >; 
m...@ietf.org; gen-art@ietf.org; 
draft-ietf-mpls-residence-time@ietf.org;
 i...@ietf.org; 
isis-cha...@ietf.org; Abhay Roy (akr) 
>
Subject: RE: [mpls] Review of draft-ietf-mpls-residence-time-12

John -

For me, this raises the age-old question of when it is/is not appropriate to 
use IGPs for flooding information.

This is clearly not TE information - you just happen to be using this in 
conjunction with MPLS - but it is a generic capability. I do not see the IGPs 
as the appropriate mechanism to flood generic interface capabilities. It also, 
as Acee has pointed out, results in flooding information to all nodes in the 
domain when only a few care about it.

[JD]  RTM support as defined in the draft would be used to provide extremely 
accurate time synchronization in an MPLS network so I would suggest that all 
nodes in such 

Re: [Gen-art] [mpls] Review of draft-ietf-mpls-residence-time-12

[Uma Chunduri]

Les,

I see what you are saying. Quick response in-line [Uma]:

--
Uma C.

From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com]
Sent: Thursday, January 19, 2017 12:11 PM
To: Uma Chunduri ; John E Drake ; 
Acee Lindem (acee) ; Alexander Vainshtein 
; Greg Mirsky 
Cc: Abhay Roy (akr) ; m...@ietf.org; isis-cha...@ietf.org; 
gen-art@ietf.org; draft-ietf-mpls-residence-time@ietf.org; Robert Sparks 
; i...@ietf.org
Subject: RE: [mpls] Review of draft-ietf-mpls-residence-time-12

Uma -

I readily admit S-BFD descriptors are - strictly speaking - a violation of the 
"non-routing info" policy - this was publicly acknowledged at the time the 
drafts were written. The exception was justified on the basis that:

  o IGPs are BFD clients
  o The S-BFD discriminator information is unique and extremely modest in size

What we have here is a proposal to start advertising non-routing related 
interface attribute information. There is nothing special or unique about RTM - 
it is simply one of many interface attributes which are generic in nature. 
Having agreed to advertise RTM in the IGPs, how would you then determine what 
other interface attributes should/should not be advertised by the IGPs? Take a 
look at your favorite vendors box and see how many interface attributes can be 
configured.
[Uma]: Well, depends on the use case.  Here I see this needs to go to egress 
node too..

It is also concerning that - when using the IGPs - we flood information which 
must be stored on every node even though the use case for it is limited to a 
much smaller subset.
I think we can and should be smarter in this regard - and given the extensive 
work being done to enhance manageability I would like to see us benefit from 
this.

The authors of draft-ietf-mpls-residence-time clearly had some thoughts in this 
regard - which is why they proposed to use RFC 6823 (GENAPP) in IS-IS to 
advertise the information -but the proposal in the draft is flawed in this 
regard. If we were to head in the "application" direction I would propose a 
much more generic "application" which is capable of advertising many interface 
attributes. However this goes back to my original concern - whether we want to 
use IGPs to flood interface attribute information unrelated to routing even if 
it is segregated under an application. Remember that RFC 6823 stipulates that a 
separate instance of the protocol (a la RFC 6822) be used for such cases.

[Uma]: +1 here. It does require additional instance and which could bring 
additional operational overhead here. I didn't bring this in because as the 
discussion is more about if this should be in IGP. I do prefer to match this to 
section 8.2 equivalent i.e., 22/222/23/223.

   Les


From: Uma Chunduri [mailto:uma.chund...@huawei.com]
Sent: Thursday, January 19, 2017 11:41 AM
To: Les Ginsberg (ginsberg); John E Drake; Acee Lindem (acee); Alexander 
Vainshtein; Greg Mirsky
Cc: Abhay Roy (akr); m...@ietf.org; 
isis-cha...@ietf.org; 
gen-art@ietf.org; 
draft-ietf-mpls-residence-time@ietf.org;
 Robert Sparks; i...@ietf.org
Subject: RE: [mpls] Review of draft-ietf-mpls-residence-time-12

I support advertising this in IGP.


>This is clearly not TE information -..
>I do not see the IGPs as the appropriate mechanism to flood generic interface 
>capabilities

We have instances where both the above are not met and we flooded information.
https://tools.ietf.org/html/rfc7883 (Les, you co-authored the same!!)
https://tools.ietf.org/html/rfc7880

--
Uma C.

From: mpls [mailto:mpls-boun...@ietf.org] On Behalf Of Les Ginsberg (ginsberg)
Sent: Thursday, January 19, 2017 9:25 AM
To: John E Drake >; Acee Lindem 
(acee) >; Alexander Vainshtein 
>; 
Greg Mirsky >
Cc: Abhay Roy (akr) >; 
m...@ietf.org; 
isis-cha...@ietf.org; 
gen-art@ietf.org; 
draft-ietf-mpls-residence-time@ietf.org;
 Robert Sparks >; 
i...@ietf.org
Subject: Re: [mpls] Review of draft-ietf-mpls-residence-time-12

John -

For me, this raises the age-old question of when it is/is not appropriate to 
use IGPs for flooding information.

This is clearly not TE information - you just happen to be using this in 
conjunction with MPLS - but it is a generic capability. I do not see the IGPs 
as the appropriate mechanism to 

Re: [Gen-art] [mpls] Review of draft-ietf-mpls-residence-time-12

[John E Drake]

Les,

I understand and I have made the same argument in other contexts and with 
similar results ("... and your point is?").

However, as I indicated in my previous email, RTM would be used as part of the 
network infrastructure as a way to provide time synchronization between the 
nodes in the network, so I would consider it similar to the S-BFDs that Uma and 
you were discussing.

Yours Irrespectively,

John

From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com]
Sent: Thursday, January 19, 2017 4:09 PM
To: John E Drake ; Acee Lindem (acee) ; 
Alexander Vainshtein ; Greg Mirsky 

Cc: Robert Sparks ; m...@ietf.org; gen-art@ietf.org; 
draft-ietf-mpls-residence-time@ietf.org; i...@ietf.org; 
isis-cha...@ietf.org; Abhay Roy (akr) 
Subject: RE: [mpls] Review of draft-ietf-mpls-residence-time-12

John -

The text you have excerpted below was trying to say two things:

1)If you want to advertise this in the IGPs the OSPF style proposal is much 
better from an implementation standpoint than the IS-IS GENAPP proposal

2)There is a larger question as to whether we should be using the IGPs for this 
at all

Statement #1 should not be interpreted to imply that I am advocating using the 
IGPs. :)

That said, we "ALWAYS" end up choosing using the IGPs to do this sort of thing 
- not because it is the "RIGHT" thing to do architecturally - but because it is 
so convenient.

I am just asking for folks to pause and think about this a bit more from an 
architectural perspective.

   Les


From: John E Drake [mailto:jdr...@juniper.net]
Sent: Thursday, January 19, 2017 12:20 PM
To: Les Ginsberg (ginsberg); Acee Lindem (acee); Alexander Vainshtein; Greg 
Mirsky
Cc: Robert Sparks; m...@ietf.org; 
gen-art@ietf.org; 
draft-ietf-mpls-residence-time@ietf.org;
 i...@ietf.org; 
isis-cha...@ietf.org; Abhay Roy (akr)
Subject: RE: [mpls] Review of draft-ietf-mpls-residence-time-12

Les,

Comments inline.

Yours Irrespectively,

John

From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com]
Sent: Thursday, January 19, 2017 12:25 PM
To: John E Drake >; Acee Lindem 
(acee) >; Alexander Vainshtein 
>; 
Greg Mirsky >
Cc: Robert Sparks >; 
m...@ietf.org; gen-art@ietf.org; 
draft-ietf-mpls-residence-time@ietf.org;
 i...@ietf.org; 
isis-cha...@ietf.org; Abhay Roy (akr) 
>
Subject: RE: [mpls] Review of draft-ietf-mpls-residence-time-12

John -

For me, this raises the age-old question of when it is/is not appropriate to 
use IGPs for flooding information.

This is clearly not TE information - you just happen to be using this in 
conjunction with MPLS - but it is a generic capability. I do not see the IGPs 
as the appropriate mechanism to flood generic interface capabilities. It also, 
as Acee has pointed out, results in flooding information to all nodes in the 
domain when only a few care about it.

[JD]  RTM support as defined in the draft would be used to provide extremely 
accurate time synchronization in an MPLS network so I would suggest that all 
nodes in such a network would be using it and hence that it does belong in the 
IGP.  As an aside, advertising it in the IGP facilitates incremental or partial 
deployment.  Your yesterday's email supports this:

"It would seem more appropriate to treat RTM information either as:

   o an extension to link attribute information already advertised by the IGPs 
(as has been suggested for OSPF) - which would suggest in IS-IS a sub-TLV of 
TLV 22(et al)

or


*As an interface attribute independent of routing protocols which could 
be retrieved utilizing network management tools"

   Les

From: John E Drake [mailto:jdr...@juniper.net]
Sent: Thursday, January 19, 2017 8:54 AM
To: Acee Lindem (acee); Alexander Vainshtein; Greg Mirsky; Les Ginsberg 
(ginsberg)
Cc: Robert Sparks; m...@ietf.org; 
gen-art@ietf.org; 
draft-ietf-mpls-residence-time@ietf.org;
 i...@ietf.org; 
isis-cha...@ietf.org; Abhay Roy (akr)
Subject: RE: [mpls] Review of draft-ietf-mpls-residence-time-12

Acee,

Relying on an omniscient controller is a non-starter in general and in 
particular because the protocol by which it would learn each 

Re: [Gen-art] [mpls] Review of draft-ietf-mpls-residence-time-12

[Les Ginsberg (ginsberg)]

John -

The text you have excerpted below was trying to say two things:

1)If you want to advertise this in the IGPs the OSPF style proposal is much 
better from an implementation standpoint than the IS-IS GENAPP proposal

2)There is a larger question as to whether we should be using the IGPs for this 
at all

Statement #1 should not be interpreted to imply that I am advocating using the 
IGPs. :)

That said, we "ALWAYS" end up choosing using the IGPs to do this sort of thing 
- not because it is the "RIGHT" thing to do architecturally - but because it is 
so convenient.

I am just asking for folks to pause and think about this a bit more from an 
architectural perspective.

   Les


From: John E Drake [mailto:jdr...@juniper.net]
Sent: Thursday, January 19, 2017 12:20 PM
To: Les Ginsberg (ginsberg); Acee Lindem (acee); Alexander Vainshtein; Greg 
Mirsky
Cc: Robert Sparks; m...@ietf.org; gen-art@ietf.org; 
draft-ietf-mpls-residence-time@ietf.org; i...@ietf.org; 
isis-cha...@ietf.org; Abhay Roy (akr)
Subject: RE: [mpls] Review of draft-ietf-mpls-residence-time-12

Les,

Comments inline.

Yours Irrespectively,

John

From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com]
Sent: Thursday, January 19, 2017 12:25 PM
To: John E Drake >; Acee Lindem 
(acee) >; Alexander Vainshtein 
>; 
Greg Mirsky >
Cc: Robert Sparks >; 
m...@ietf.org; gen-art@ietf.org; 
draft-ietf-mpls-residence-time@ietf.org;
 i...@ietf.org; 
isis-cha...@ietf.org; Abhay Roy (akr) 
>
Subject: RE: [mpls] Review of draft-ietf-mpls-residence-time-12

John -

For me, this raises the age-old question of when it is/is not appropriate to 
use IGPs for flooding information.

This is clearly not TE information - you just happen to be using this in 
conjunction with MPLS - but it is a generic capability. I do not see the IGPs 
as the appropriate mechanism to flood generic interface capabilities. It also, 
as Acee has pointed out, results in flooding information to all nodes in the 
domain when only a few care about it.

[JD]  RTM support as defined in the draft would be used to provide extremely 
accurate time synchronization in an MPLS network so I would suggest that all 
nodes in such a network would be using it and hence that it does belong in the 
IGP.  As an aside, advertising it in the IGP facilitates incremental or partial 
deployment.  Your yesterday's email supports this:

"It would seem more appropriate to treat RTM information either as:

   o an extension to link attribute information already advertised by the IGPs 
(as has been suggested for OSPF) - which would suggest in IS-IS a sub-TLV of 
TLV 22(et al)

or


*As an interface attribute independent of routing protocols which could 
be retrieved utilizing network management tools"

   Les

From: John E Drake [mailto:jdr...@juniper.net]
Sent: Thursday, January 19, 2017 8:54 AM
To: Acee Lindem (acee); Alexander Vainshtein; Greg Mirsky; Les Ginsberg 
(ginsberg)
Cc: Robert Sparks; m...@ietf.org; 
gen-art@ietf.org; 
draft-ietf-mpls-residence-time@ietf.org;
 i...@ietf.org; 
isis-cha...@ietf.org; Abhay Roy (akr)
Subject: RE: [mpls] Review of draft-ietf-mpls-residence-time-12

Acee,

Relying on an omniscient controller is a non-starter in general and in 
particular because the protocol by which it would learn each node's RTM 
capabilities and distribute them to the other nodes is undefined.  Further, one 
of the ways by which an omniscient controller learns a node's capabilities is 
by snooping the link/state database.

Yours Irrespectively,

John

From: Acee Lindem (acee) [mailto:a...@cisco.com]
Sent: Thursday, January 19, 2017 11:47 AM
To: John E Drake >; Alexander 
Vainshtein 
>; 
Greg Mirsky >; Les Ginsberg 
(ginsberg) >
Cc: Robert Sparks >; 
m...@ietf.org; gen-art@ietf.org; 
draft-ietf-mpls-residence-time@ietf.org;
 i...@ietf.org; 
isis-cha...@ietf.org; Abhay Roy (akr) 
>
Subject: Re: [mpls] Review of draft-ietf-mpls-residence-time-12

Re: [Gen-art] [mpls] Review of draft-ietf-mpls-residence-time-12

[John E Drake]

Les,

Comments inline.

Yours Irrespectively,

John

From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com]
Sent: Thursday, January 19, 2017 12:25 PM
To: John E Drake ; Acee Lindem (acee) ; 
Alexander Vainshtein ; Greg Mirsky 

Cc: Robert Sparks ; m...@ietf.org; gen-art@ietf.org; 
draft-ietf-mpls-residence-time@ietf.org; i...@ietf.org; 
isis-cha...@ietf.org; Abhay Roy (akr) 
Subject: RE: [mpls] Review of draft-ietf-mpls-residence-time-12

John -

For me, this raises the age-old question of when it is/is not appropriate to 
use IGPs for flooding information.

This is clearly not TE information - you just happen to be using this in 
conjunction with MPLS - but it is a generic capability. I do not see the IGPs 
as the appropriate mechanism to flood generic interface capabilities. It also, 
as Acee has pointed out, results in flooding information to all nodes in the 
domain when only a few care about it.

[JD]  RTM support as defined in the draft would be used to provide extremely 
accurate time synchronization in an MPLS network so I would suggest that all 
nodes in such a network would be using it and hence that it does belong in the 
IGP.  As an aside, advertising it in the IGP facilitates incremental or partial 
deployment.  Your yesterday's email supports this:

"It would seem more appropriate to treat RTM information either as:

   o an extension to link attribute information already advertised by the IGPs 
(as has been suggested for OSPF) - which would suggest in IS-IS a sub-TLV of 
TLV 22(et al)

or


*As an interface attribute independent of routing protocols which could 
be retrieved utilizing network management tools"

   Les

From: John E Drake [mailto:jdr...@juniper.net]
Sent: Thursday, January 19, 2017 8:54 AM
To: Acee Lindem (acee); Alexander Vainshtein; Greg Mirsky; Les Ginsberg 
(ginsberg)
Cc: Robert Sparks; m...@ietf.org; 
gen-art@ietf.org; 
draft-ietf-mpls-residence-time@ietf.org;
 i...@ietf.org; 
isis-cha...@ietf.org; Abhay Roy (akr)
Subject: RE: [mpls] Review of draft-ietf-mpls-residence-time-12

Acee,

Relying on an omniscient controller is a non-starter in general and in 
particular because the protocol by which it would learn each node's RTM 
capabilities and distribute them to the other nodes is undefined.  Further, one 
of the ways by which an omniscient controller learns a node's capabilities is 
by snooping the link/state database.

Yours Irrespectively,

John

From: Acee Lindem (acee) [mailto:a...@cisco.com]
Sent: Thursday, January 19, 2017 11:47 AM
To: John E Drake >; Alexander 
Vainshtein 
>; 
Greg Mirsky >; Les Ginsberg 
(ginsberg) >
Cc: Robert Sparks >; 
m...@ietf.org; gen-art@ietf.org; 
draft-ietf-mpls-residence-time@ietf.org;
 i...@ietf.org; 
isis-cha...@ietf.org; Abhay Roy (akr) 
>
Subject: Re: [mpls] Review of draft-ietf-mpls-residence-time-12

Hi John,

From: John E Drake >
Date: Thursday, January 19, 2017 at 10:43 AM
To: Acee Lindem >, Alexander Vainshtein 
>, 
Greg Mirsky >, "Les 
Ginsberg (ginsberg)" >
Cc: Robert Sparks >, 
"m...@ietf.org" >, 
"gen-art@ietf.org" 
>, 
"draft-ietf-mpls-residence-time@ietf.org"
 
>,
 "i...@ietf.org" >, 
"isis-cha...@ietf.org" 
>, "Abhay Roy (akr)" 
>
Subject: RE: [mpls] Review of draft-ietf-mpls-residence-time-12

Acee,

We discussed all of this with you over a year ago and used your guidance in 
adding the indication of RTM capability to OSPF.

I'm sorry but I focused mainly on the OSPF protocol aspects then and didn't 
question the use case. This 

Re: [Gen-art] [mpls] Review of draft-ietf-mpls-residence-time-12

[Les Ginsberg (ginsberg)]

Uma -

I readily admit S-BFD descriptors are - strictly speaking - a violation of the 
"non-routing info" policy - this was publicly acknowledged at the time the 
drafts were written. The exception was justified on the basis that:

  o IGPs are BFD clients
  o The S-BFD discriminator information is unique and extremely modest in size

What we have here is a proposal to start advertising non-routing related 
interface attribute information. There is nothing special or unique about RTM - 
it is simply one of many interface attributes which are generic in nature. 
Having agreed to advertise RTM in the IGPs, how would you then determine what 
other interface attributes should/should not be advertised by the IGPs? Take a 
look at your favorite vendors box and see how many interface attributes can be 
configured.

It is also concerning that - when using the IGPs - we flood information which 
must be stored on every node even though the use case for it is limited to a 
much smaller subset.

I think we can and should be smarter in this regard - and given the extensive 
work being done to enhance manageability I would like to see us benefit from 
this.

The authors of draft-ietf-mpls-residence-time clearly had some thoughts in this 
regard - which is why they proposed to use RFC 6823 (GENAPP) in IS-IS to 
advertise the information -but the proposal in the draft is flawed in this 
regard. If we were to head in the "application" direction I would propose a 
much more generic "application" which is capable of advertising many interface 
attributes. However this goes back to my original concern - whether we want to 
use IGPs to flood interface attribute information unrelated to routing even if 
it is segregated under an application. Remember that RFC 6823 stipulates that a 
separate instance of the protocol (a la RFC 6822) be used for such cases.

   Les


From: Uma Chunduri [mailto:uma.chund...@huawei.com]
Sent: Thursday, January 19, 2017 11:41 AM
To: Les Ginsberg (ginsberg); John E Drake; Acee Lindem (acee); Alexander 
Vainshtein; Greg Mirsky
Cc: Abhay Roy (akr); m...@ietf.org; isis-cha...@ietf.org; gen-art@ietf.org; 
draft-ietf-mpls-residence-time@ietf.org; Robert Sparks; i...@ietf.org
Subject: RE: [mpls] Review of draft-ietf-mpls-residence-time-12

I support advertising this in IGP.


>This is clearly not TE information -..
>I do not see the IGPs as the appropriate mechanism to flood generic interface 
>capabilities

We have instances where both the above are not met and we flooded information.
https://tools.ietf.org/html/rfc7883 (Les, you co-authored the same!!)
https://tools.ietf.org/html/rfc7880

--
Uma C.

From: mpls [mailto:mpls-boun...@ietf.org] On Behalf Of Les Ginsberg (ginsberg)
Sent: Thursday, January 19, 2017 9:25 AM
To: John E Drake ; Acee Lindem (acee) ; 
Alexander Vainshtein ; Greg Mirsky 

Cc: Abhay Roy (akr) ; m...@ietf.org; isis-cha...@ietf.org; 
gen-art@ietf.org; draft-ietf-mpls-residence-time@ietf.org; Robert Sparks 
; i...@ietf.org
Subject: Re: [mpls] Review of draft-ietf-mpls-residence-time-12

John -

For me, this raises the age-old question of when it is/is not appropriate to 
use IGPs for flooding information.

This is clearly not TE information - you just happen to be using this in 
conjunction with MPLS - but it is a generic capability. I do not see the IGPs 
as the appropriate mechanism to flood generic interface capabilities. It also, 
as Acee has pointed out, results in flooding information to all nodes in the 
domain when only a few care about it.

   Les

From: John E Drake [mailto:jdr...@juniper.net]
Sent: Thursday, January 19, 2017 8:54 AM
To: Acee Lindem (acee); Alexander Vainshtein; Greg Mirsky; Les Ginsberg 
(ginsberg)
Cc: Robert Sparks; m...@ietf.org; 
gen-art@ietf.org; 
draft-ietf-mpls-residence-time@ietf.org;
 i...@ietf.org; 
isis-cha...@ietf.org; Abhay Roy (akr)
Subject: RE: [mpls] Review of draft-ietf-mpls-residence-time-12

Acee,

Relying on an omniscient controller is a non-starter in general and in 
particular because the protocol by which it would learn each node's RTM 
capabilities and distribute them to the other nodes is undefined.  Further, one 
of the ways by which an omniscient controller learns a node's capabilities is 
by snooping the link/state database.

Yours Irrespectively,

John

From: Acee Lindem (acee) [mailto:a...@cisco.com]
Sent: Thursday, January 19, 2017 11:47 AM
To: John E Drake >; Alexander 
Vainshtein 
>; 
Greg Mirsky >; Les Ginsberg 
(ginsberg) >

Re: [Gen-art] [mpls] Review of draft-ietf-mpls-residence-time-12

[Uma Chunduri]

I support advertising this in IGP.


>This is clearly not TE information -..
>I do not see the IGPs as the appropriate mechanism to flood generic interface 
>capabilities

We have instances where both the above are not met and we flooded information.
https://tools.ietf.org/html/rfc7883 (Les, you co-authored the same!!)
https://tools.ietf.org/html/rfc7880

--
Uma C.

From: mpls [mailto:mpls-boun...@ietf.org] On Behalf Of Les Ginsberg (ginsberg)
Sent: Thursday, January 19, 2017 9:25 AM
To: John E Drake ; Acee Lindem (acee) ; 
Alexander Vainshtein ; Greg Mirsky 

Cc: Abhay Roy (akr) ; m...@ietf.org; isis-cha...@ietf.org; 
gen-art@ietf.org; draft-ietf-mpls-residence-time@ietf.org; Robert Sparks 
; i...@ietf.org
Subject: Re: [mpls] Review of draft-ietf-mpls-residence-time-12

John -

For me, this raises the age-old question of when it is/is not appropriate to 
use IGPs for flooding information.

This is clearly not TE information - you just happen to be using this in 
conjunction with MPLS - but it is a generic capability. I do not see the IGPs 
as the appropriate mechanism to flood generic interface capabilities. It also, 
as Acee has pointed out, results in flooding information to all nodes in the 
domain when only a few care about it.

   Les

From: John E Drake [mailto:jdr...@juniper.net]
Sent: Thursday, January 19, 2017 8:54 AM
To: Acee Lindem (acee); Alexander Vainshtein; Greg Mirsky; Les Ginsberg 
(ginsberg)
Cc: Robert Sparks; m...@ietf.org; 
gen-art@ietf.org; 
draft-ietf-mpls-residence-time@ietf.org;
 i...@ietf.org; 
isis-cha...@ietf.org; Abhay Roy (akr)
Subject: RE: [mpls] Review of draft-ietf-mpls-residence-time-12

Acee,

Relying on an omniscient controller is a non-starter in general and in 
particular because the protocol by which it would learn each node's RTM 
capabilities and distribute them to the other nodes is undefined.  Further, one 
of the ways by which an omniscient controller learns a node's capabilities is 
by snooping the link/state database.

Yours Irrespectively,

John

From: Acee Lindem (acee) [mailto:a...@cisco.com]
Sent: Thursday, January 19, 2017 11:47 AM
To: John E Drake >; Alexander 
Vainshtein 
>; 
Greg Mirsky >; Les Ginsberg 
(ginsberg) >
Cc: Robert Sparks >; 
m...@ietf.org; gen-art@ietf.org; 
draft-ietf-mpls-residence-time@ietf.org;
 i...@ietf.org; 
isis-cha...@ietf.org; Abhay Roy (akr) 
>
Subject: Re: [mpls] Review of draft-ietf-mpls-residence-time-12

Hi John,

From: John E Drake >
Date: Thursday, January 19, 2017 at 10:43 AM
To: Acee Lindem >, Alexander Vainshtein 
>, 
Greg Mirsky >, "Les 
Ginsberg (ginsberg)" >
Cc: Robert Sparks >, 
"m...@ietf.org" >, 
"gen-art@ietf.org" 
>, 
"draft-ietf-mpls-residence-time@ietf.org"
 
>,
 "i...@ietf.org" >, 
"isis-cha...@ietf.org" 
>, "Abhay Roy (akr)" 
>
Subject: RE: [mpls] Review of draft-ietf-mpls-residence-time-12

Acee,

We discussed all of this with you over a year ago and used your guidance in 
adding the indication of RTM capability to OSPF.

I'm sorry but I focused mainly on the OSPF protocol aspects then and didn't 
question the use case. This question came up in the IS-IS WG discussions.

Thanks,
Acee


Yours Irrespectively,

John

From: Acee Lindem (acee) [mailto:a...@cisco.com]
Sent: Thursday, January 19, 2017 11:38 AM
To: Alexander Vainshtein 
>; 
Greg Mirsky >; Les Ginsberg 
(ginsberg) 

Re: [Gen-art] [mpls] Review of draft-ietf-mpls-residence-time-12

[Les Ginsberg (ginsberg)]

John -

For me, this raises the age-old question of when it is/is not appropriate to 
use IGPs for flooding information.

This is clearly not TE information - you just happen to be using this in 
conjunction with MPLS - but it is a generic capability. I do not see the IGPs 
as the appropriate mechanism to flood generic interface capabilities. It also, 
as Acee has pointed out, results in flooding information to all nodes in the 
domain when only a few care about it.

   Les

From: John E Drake [mailto:jdr...@juniper.net]
Sent: Thursday, January 19, 2017 8:54 AM
To: Acee Lindem (acee); Alexander Vainshtein; Greg Mirsky; Les Ginsberg 
(ginsberg)
Cc: Robert Sparks; m...@ietf.org; gen-art@ietf.org; 
draft-ietf-mpls-residence-time@ietf.org; i...@ietf.org; 
isis-cha...@ietf.org; Abhay Roy (akr)
Subject: RE: [mpls] Review of draft-ietf-mpls-residence-time-12

Acee,

Relying on an omniscient controller is a non-starter in general and in 
particular because the protocol by which it would learn each node's RTM 
capabilities and distribute them to the other nodes is undefined.  Further, one 
of the ways by which an omniscient controller learns a node's capabilities is 
by snooping the link/state database.

Yours Irrespectively,

John

From: Acee Lindem (acee) [mailto:a...@cisco.com]
Sent: Thursday, January 19, 2017 11:47 AM
To: John E Drake >; Alexander 
Vainshtein 
>; 
Greg Mirsky >; Les Ginsberg 
(ginsberg) >
Cc: Robert Sparks >; 
m...@ietf.org; gen-art@ietf.org; 
draft-ietf-mpls-residence-time@ietf.org;
 i...@ietf.org; 
isis-cha...@ietf.org; Abhay Roy (akr) 
>
Subject: Re: [mpls] Review of draft-ietf-mpls-residence-time-12

Hi John,

From: John E Drake >
Date: Thursday, January 19, 2017 at 10:43 AM
To: Acee Lindem >, Alexander Vainshtein 
>, 
Greg Mirsky >, "Les 
Ginsberg (ginsberg)" >
Cc: Robert Sparks >, 
"m...@ietf.org" >, 
"gen-art@ietf.org" 
>, 
"draft-ietf-mpls-residence-time@ietf.org"
 
>,
 "i...@ietf.org" >, 
"isis-cha...@ietf.org" 
>, "Abhay Roy (akr)" 
>
Subject: RE: [mpls] Review of draft-ietf-mpls-residence-time-12

Acee,

We discussed all of this with you over a year ago and used your guidance in 
adding the indication of RTM capability to OSPF.

I'm sorry but I focused mainly on the OSPF protocol aspects then and didn't 
question the use case. This question came up in the IS-IS WG discussions.

Thanks,
Acee


Yours Irrespectively,

John

From: Acee Lindem (acee) [mailto:a...@cisco.com]
Sent: Thursday, January 19, 2017 11:38 AM
To: Alexander Vainshtein 
>; 
Greg Mirsky >; Les Ginsberg 
(ginsberg) >
Cc: Robert Sparks >; 
m...@ietf.org; gen-art@ietf.org; 
draft-ietf-mpls-residence-time@ietf.org;
 i...@ietf.org; 
isis-cha...@ietf.org; Abhay Roy (akr) 
>
Subject: Re: [mpls] Review of draft-ietf-mpls-residence-time-12

I guess what we were trying to envision the use case and whether it makes sense 
for all the nodes in the IGP routing domain to have this information. Would the 
LSP ingress LSR only need to if the egress LSR supports RTM and it is best 
effort recording for transit LSRs in the path?

Additionally, if it is needed in the IGPs, should there also be a BGP-LS Link 
Attribute TLV proposed?

Thanks,
Acee

From: Alexander Vainshtein 
>
Date: Thursday, January 19, 2017 at 10:15 AM
To: Greg Mirsky 

Re: [Gen-art] [mpls] Review of draft-ietf-mpls-residence-time-12

[John E Drake]

Acee,

Relying on an omniscient controller is a non-starter in general and in 
particular because the protocol by which it would learn each node's RTM 
capabilities and distribute them to the other nodes is undefined.  Further, one 
of the ways by which an omniscient controller learns a node's capabilities is 
by snooping the link/state database.

Yours Irrespectively,

John

From: Acee Lindem (acee) [mailto:a...@cisco.com]
Sent: Thursday, January 19, 2017 11:47 AM
To: John E Drake ; Alexander Vainshtein 
; Greg Mirsky ; Les 
Ginsberg (ginsberg) 
Cc: Robert Sparks ; m...@ietf.org; gen-art@ietf.org; 
draft-ietf-mpls-residence-time@ietf.org; i...@ietf.org; 
isis-cha...@ietf.org; Abhay Roy (akr) 
Subject: Re: [mpls] Review of draft-ietf-mpls-residence-time-12

Hi John,

From: John E Drake >
Date: Thursday, January 19, 2017 at 10:43 AM
To: Acee Lindem >, Alexander Vainshtein 
>, 
Greg Mirsky >, "Les 
Ginsberg (ginsberg)" >
Cc: Robert Sparks >, 
"m...@ietf.org" >, 
"gen-art@ietf.org" 
>, 
"draft-ietf-mpls-residence-time@ietf.org"
 
>,
 "i...@ietf.org" >, 
"isis-cha...@ietf.org" 
>, "Abhay Roy (akr)" 
>
Subject: RE: [mpls] Review of draft-ietf-mpls-residence-time-12

Acee,

We discussed all of this with you over a year ago and used your guidance in 
adding the indication of RTM capability to OSPF.

I'm sorry but I focused mainly on the OSPF protocol aspects then and didn't 
question the use case. This question came up in the IS-IS WG discussions.

Thanks,
Acee


Yours Irrespectively,

John

From: Acee Lindem (acee) [mailto:a...@cisco.com]
Sent: Thursday, January 19, 2017 11:38 AM
To: Alexander Vainshtein 
>; 
Greg Mirsky >; Les Ginsberg 
(ginsberg) >
Cc: Robert Sparks >; 
m...@ietf.org; gen-art@ietf.org; 
draft-ietf-mpls-residence-time@ietf.org;
 i...@ietf.org; 
isis-cha...@ietf.org; Abhay Roy (akr) 
>
Subject: Re: [mpls] Review of draft-ietf-mpls-residence-time-12

I guess what we were trying to envision the use case and whether it makes sense 
for all the nodes in the IGP routing domain to have this information. Would the 
LSP ingress LSR only need to if the egress LSR supports RTM and it is best 
effort recording for transit LSRs in the path?

Additionally, if it is needed in the IGPs, should there also be a BGP-LS Link 
Attribute TLV proposed?

Thanks,
Acee

From: Alexander Vainshtein 
>
Date: Thursday, January 19, 2017 at 10:15 AM
To: Greg Mirsky >, "Les 
Ginsberg (ginsberg)" >
Cc: Acee Lindem >, Robert Sparks 
>, 
"m...@ietf.org" >, 
"gen-art@ietf.org" 
>, 
"draft-ietf-mpls-residence-time@ietf.org"
 
>,
 "i...@ietf.org" >, 
"isis-cha...@ietf.org" 
>, "Abhay Roy (akr)" 
>
Subject: RE: [mpls] Review of draft-ietf-mpls-residence-time-12

Hi all,
I concur with Greg: from my POV an interoperable solution should not depend on 
an omniscient NMS client distributing information about capabilities of each 
node to each other node.


Regards,
Sasha

Office: +972-39266302
Cell:  +972-549266302
Email:   

Re: [Gen-art] [mpls] Review of draft-ietf-mpls-residence-time-12

[John E Drake]

Acee,

We discussed all of this with you over a year ago and used your guidance in 
adding the indication of RTM capability to OSPF.

Yours Irrespectively,

John

From: Acee Lindem (acee) [mailto:a...@cisco.com]
Sent: Thursday, January 19, 2017 11:38 AM
To: Alexander Vainshtein ; Greg Mirsky 
; Les Ginsberg (ginsberg) 
Cc: Robert Sparks ; m...@ietf.org; gen-art@ietf.org; 
draft-ietf-mpls-residence-time@ietf.org; i...@ietf.org; 
isis-cha...@ietf.org; Abhay Roy (akr) 
Subject: Re: [mpls] Review of draft-ietf-mpls-residence-time-12

I guess what we were trying to envision the use case and whether it makes sense 
for all the nodes in the IGP routing domain to have this information. Would the 
LSP ingress LSR only need to if the egress LSR supports RTM and it is best 
effort recording for transit LSRs in the path?

Additionally, if it is needed in the IGPs, should there also be a BGP-LS Link 
Attribute TLV proposed?

Thanks,
Acee

From: Alexander Vainshtein 
>
Date: Thursday, January 19, 2017 at 10:15 AM
To: Greg Mirsky >, "Les 
Ginsberg (ginsberg)" >
Cc: Acee Lindem >, Robert Sparks 
>, 
"m...@ietf.org" >, 
"gen-art@ietf.org" 
>, 
"draft-ietf-mpls-residence-time@ietf.org"
 
>,
 "i...@ietf.org" >, 
"isis-cha...@ietf.org" 
>, "Abhay Roy (akr)" 
>
Subject: RE: [mpls] Review of draft-ietf-mpls-residence-time-12

Hi all,
I concur with Greg: from my POV an interoperable solution should not depend on 
an omniscient NMS client distributing information about capabilities of each 
node to each other node.


Regards,
Sasha

Office: +972-39266302
Cell:  +972-549266302
Email:   
alexander.vainsht...@ecitele.com

From: Greg Mirsky [mailto:gregimir...@gmail.com]
Sent: Thursday, January 19, 2017 6:01 PM
To: Les Ginsberg (ginsberg) >
Cc: Acee Lindem (acee) >; Robert Sparks 
>; 
m...@ietf.org; gen-art@ietf.org; 
draft-ietf-mpls-residence-time@ietf.org;
 i...@ietf.org; 
isis-cha...@ietf.org; Abhay Roy (akr) 
>
Subject: Re: [mpls] Review of draft-ietf-mpls-residence-time-12

Hi Les,
I believe that IGP extensions to advertise RTM capability are required.

Regards,
Greg

On Thu, Jan 19, 2017 at 7:57 AM, Les Ginsberg (ginsberg) 
> wrote:
Greg -

I am having trouble understanding your response.
The question we are raising is whether we should extend the IGPs to support 
advertising RTM capability - an alternative being to retrieve the capability 
via network management.

Saying that the IGP functionality is optional and/or wouldn't always be 
advertised doesn't really answer the question of whether we should or should 
not define the IGP extensions.

Could you respond more directly to this point?

   Les


From: Greg Mirsky [mailto:gregimir...@gmail.com]
Sent: Thursday, January 19, 2017 7:44 AM
To: Acee Lindem (acee)
Cc: Robert Sparks; m...@ietf.org; 
gen-art@ietf.org; 
draft-ietf-mpls-residence-time@ietf.org;
 i...@ietf.org; Les Ginsberg (ginsberg); 
isis-cha...@ietf.org; Abhay Roy (akr)

Subject: Re: [mpls] Review of draft-ietf-mpls-residence-time-12

Hi Acee,
the draft defines optional functionality. If an operator has no use neither for 
PTP's Transparent Clock, nor RTM itself as performance metric, then RTM sub-TLV 
would not be included and thus it would not be flooded. Of course, it be right 
to reflect RTM capability through YANG data model, thus allowing SDN scenario 
you've described.

Regards,
Greg

On Wed, Jan 18, 2017 at 2:51 PM, Acee Lindem (acee) 
> wrote:
Hi Greg,

Although it is a bit late, we've had some discussions amongst the IS-IS and 
OSPF chairs and are wondering 

Re: [Gen-art] [mpls] Review of draft-ietf-mpls-residence-time-12

[Acee Lindem (acee)]

Hi John,

From: John E Drake >
Date: Thursday, January 19, 2017 at 10:43 AM
To: Acee Lindem >, Alexander Vainshtein 
>, 
Greg Mirsky >, "Les 
Ginsberg (ginsberg)" >
Cc: Robert Sparks >, 
"m...@ietf.org" >, 
"gen-art@ietf.org" 
>, 
"draft-ietf-mpls-residence-time@ietf.org"
 
>,
 "i...@ietf.org" >, 
"isis-cha...@ietf.org" 
>, "Abhay Roy (akr)" 
>
Subject: RE: [mpls] Review of draft-ietf-mpls-residence-time-12

Acee,

We discussed all of this with you over a year ago and used your guidance in 
adding the indication of RTM capability to OSPF.

I’m sorry but I focused mainly on the OSPF protocol aspects then and didn’t 
question the use case. This question came up in the IS-IS WG discussions.

Thanks,
Acee


Yours Irrespectively,

John

From: Acee Lindem (acee) [mailto:a...@cisco.com]
Sent: Thursday, January 19, 2017 11:38 AM
To: Alexander Vainshtein 
>; 
Greg Mirsky >; Les Ginsberg 
(ginsberg) >
Cc: Robert Sparks >; 
m...@ietf.org; gen-art@ietf.org; 
draft-ietf-mpls-residence-time@ietf.org;
 i...@ietf.org; 
isis-cha...@ietf.org; Abhay Roy (akr) 
>
Subject: Re: [mpls] Review of draft-ietf-mpls-residence-time-12

I guess what we were trying to envision the use case and whether it makes sense 
for all the nodes in the IGP routing domain to have this information. Would the 
LSP ingress LSR only need to if the egress LSR supports RTM and it is best 
effort recording for transit LSRs in the path?

Additionally, if it is needed in the IGPs, should there also be a BGP-LS Link 
Attribute TLV proposed?

Thanks,
Acee

From: Alexander Vainshtein 
>
Date: Thursday, January 19, 2017 at 10:15 AM
To: Greg Mirsky >, "Les 
Ginsberg (ginsberg)" >
Cc: Acee Lindem >, Robert Sparks 
>, 
"m...@ietf.org" >, 
"gen-art@ietf.org" 
>, 
"draft-ietf-mpls-residence-time@ietf.org"
 
>,
 "i...@ietf.org" >, 
"isis-cha...@ietf.org" 
>, "Abhay Roy (akr)" 
>
Subject: RE: [mpls] Review of draft-ietf-mpls-residence-time-12

Hi all,
I concur with Greg: from my POV an interoperable solution should not depend on 
an omniscient NMS client distributing information about capabilities of each 
node to each other node.


Regards,
Sasha

Office: +972-39266302
Cell:  +972-549266302
Email:   
alexander.vainsht...@ecitele.com

From: Greg Mirsky [mailto:gregimir...@gmail.com]
Sent: Thursday, January 19, 2017 6:01 PM
To: Les Ginsberg (ginsberg) >
Cc: Acee Lindem (acee) >; Robert Sparks 
>; 
m...@ietf.org; gen-art@ietf.org; 
draft-ietf-mpls-residence-time@ietf.org;
 i...@ietf.org; 
isis-cha...@ietf.org; Abhay Roy (akr) 
>
Subject: Re: [mpls] Review of draft-ietf-mpls-residence-time-12

Hi Les,
I believe that IGP extensions to advertise RTM capability are required.

Regards,
Greg

On Thu, Jan 19, 2017 at 7:57 AM, Les Ginsberg (ginsberg) 

Re: [Gen-art] [mpls] Review of draft-ietf-mpls-residence-time-12

[Acee Lindem (acee)]

I guess what we were trying to envision the use case and whether it makes sense 
for all the nodes in the IGP routing domain to have this information. Would the 
LSP ingress LSR only need to if the egress LSR supports RTM and it is best 
effort recording for transit LSRs in the path?

Additionally, if it is needed in the IGPs, should there also be a BGP-LS Link 
Attribute TLV proposed?

Thanks,
Acee

From: Alexander Vainshtein 
>
Date: Thursday, January 19, 2017 at 10:15 AM
To: Greg Mirsky >, "Les 
Ginsberg (ginsberg)" >
Cc: Acee Lindem >, Robert Sparks 
>, 
"m...@ietf.org" >, 
"gen-art@ietf.org" 
>, 
"draft-ietf-mpls-residence-time@ietf.org"
 
>,
 "i...@ietf.org" >, 
"isis-cha...@ietf.org" 
>, "Abhay Roy (akr)" 
>
Subject: RE: [mpls] Review of draft-ietf-mpls-residence-time-12

Hi all,
I concur with Greg: from my POV an interoperable solution should not depend on 
an omniscient NMS client distributing information about capabilities of each 
node to each other node.


Regards,
Sasha

Office: +972-39266302
Cell:  +972-549266302
Email:   
alexander.vainsht...@ecitele.com

From: Greg Mirsky [mailto:gregimir...@gmail.com]
Sent: Thursday, January 19, 2017 6:01 PM
To: Les Ginsberg (ginsberg) >
Cc: Acee Lindem (acee) >; Robert Sparks 
>; 
m...@ietf.org; gen-art@ietf.org; 
draft-ietf-mpls-residence-time@ietf.org;
 i...@ietf.org; 
isis-cha...@ietf.org; Abhay Roy (akr) 
>
Subject: Re: [mpls] Review of draft-ietf-mpls-residence-time-12

Hi Les,
I believe that IGP extensions to advertise RTM capability are required.

Regards,
Greg

On Thu, Jan 19, 2017 at 7:57 AM, Les Ginsberg (ginsberg) 
> wrote:
Greg –

I am having trouble understanding your response.
The question we are raising is whether we should extend the IGPs to support 
advertising RTM capability – an alternative being to retrieve the capability 
via network management.

Saying that the IGP functionality is optional and/or wouldn’t always be 
advertised doesn’t really answer the question of whether we should or should 
not define the IGP extensions.

Could you respond more directly to this point?

   Les


From: Greg Mirsky [mailto:gregimir...@gmail.com]
Sent: Thursday, January 19, 2017 7:44 AM
To: Acee Lindem (acee)
Cc: Robert Sparks; m...@ietf.org; 
gen-art@ietf.org; 
draft-ietf-mpls-residence-time@ietf.org;
 i...@ietf.org; Les Ginsberg (ginsberg); 
isis-cha...@ietf.org; Abhay Roy (akr)

Subject: Re: [mpls] Review of draft-ietf-mpls-residence-time-12

Hi Acee,
the draft defines optional functionality. If an operator has no use neither for 
PTP's Transparent Clock, nor RTM itself as performance metric, then RTM sub-TLV 
would not be included and thus it would not be flooded. Of course, it be right 
to reflect RTM capability through YANG data model, thus allowing SDN scenario 
you've described.

Regards,
Greg

On Wed, Jan 18, 2017 at 2:51 PM, Acee Lindem (acee) 
> wrote:
Hi Greg,

Although it is a bit late, we’ve had some discussions amongst the IS-IS and 
OSPF chairs and are wondering whether the interface capability belongs in the 
IGPs. This will be flooded throughout the entire routing domain – is it really 
needed on every node or will it the RTM testing be initiated from an omniscient 
NMS client that would know the capabilities of each node or easily query them 
using YANG?

Thanks,
Acee

From: mpls > on behalf of 
Greg Mirsky >
Date: Wednesday, January 18, 2017 at 1:25 PM
To: Robert Sparks >
Cc: "m...@ietf.org" 
>, 

Re: [Gen-art] [mpls] Review of draft-ietf-mpls-residence-time-12

[Alexander Vainshtein]

Hi all,
I concur with Greg: from my POV an interoperable solution should not depend on 
an omniscient NMS client distributing information about capabilities of each 
node to each other node.


Regards,
Sasha

Office: +972-39266302
Cell:  +972-549266302
Email:   alexander.vainsht...@ecitele.com

From: Greg Mirsky [mailto:gregimir...@gmail.com]
Sent: Thursday, January 19, 2017 6:01 PM
To: Les Ginsberg (ginsberg) 
Cc: Acee Lindem (acee) ; Robert Sparks ; 
m...@ietf.org; gen-art@ietf.org; draft-ietf-mpls-residence-time@ietf.org; 
i...@ietf.org; isis-cha...@ietf.org; Abhay Roy (akr) 
Subject: Re: [mpls] Review of draft-ietf-mpls-residence-time-12

Hi Les,
I believe that IGP extensions to advertise RTM capability are required.

Regards,
Greg

On Thu, Jan 19, 2017 at 7:57 AM, Les Ginsberg (ginsberg) 
> wrote:
Greg –

I am having trouble understanding your response.
The question we are raising is whether we should extend the IGPs to support 
advertising RTM capability – an alternative being to retrieve the capability 
via network management.

Saying that the IGP functionality is optional and/or wouldn’t always be 
advertised doesn’t really answer the question of whether we should or should 
not define the IGP extensions.

Could you respond more directly to this point?

   Les


From: Greg Mirsky [mailto:gregimir...@gmail.com]
Sent: Thursday, January 19, 2017 7:44 AM
To: Acee Lindem (acee)
Cc: Robert Sparks; m...@ietf.org; 
gen-art@ietf.org; 
draft-ietf-mpls-residence-time@ietf.org;
 i...@ietf.org; Les Ginsberg (ginsberg); 
isis-cha...@ietf.org; Abhay Roy (akr)

Subject: Re: [mpls] Review of draft-ietf-mpls-residence-time-12

Hi Acee,
the draft defines optional functionality. If an operator has no use neither for 
PTP's Transparent Clock, nor RTM itself as performance metric, then RTM sub-TLV 
would not be included and thus it would not be flooded. Of course, it be right 
to reflect RTM capability through YANG data model, thus allowing SDN scenario 
you've described.

Regards,
Greg

On Wed, Jan 18, 2017 at 2:51 PM, Acee Lindem (acee) 
> wrote:
Hi Greg,

Although it is a bit late, we’ve had some discussions amongst the IS-IS and 
OSPF chairs and are wondering whether the interface capability belongs in the 
IGPs. This will be flooded throughout the entire routing domain – is it really 
needed on every node or will it the RTM testing be initiated from an omniscient 
NMS client that would know the capabilities of each node or easily query them 
using YANG?

Thanks,
Acee

From: mpls > on behalf of 
Greg Mirsky >
Date: Wednesday, January 18, 2017 at 1:25 PM
To: Robert Sparks >
Cc: "m...@ietf.org" 
>, 
"gen-art@ietf.org" 
>, 
"draft-ietf-mpls-residence-time@ietf.org"
 
>,
 "i...@ietf.org" >
Subject: Re: [mpls] Review of draft-ietf-mpls-residence-time-12

Hi Robert,
thank you for the most expedient review and comments. I'll make changes in 
Section 2 per your suggestion.

Regards,
Greg

On Wed, Jan 18, 2017 at 10:34 AM, Robert Sparks 
> wrote:

The changes all look good.

I still think you should say something in the document about what "the time of 
packet arrival" and "transmission" means, and call out the point you made about 
being careful to not introduce apparent jitter by not making those measurements 
consistently. (The definitions you point to in your earlier mail from G.8013 
don't really help - they just say "time of packet arrival". Again, the first 
and last bit are likely to be several nanoseconds apart so I think it matters. 
Perhaps you're saying it doesn't matter as long as each node is consistent 
(there will be error in the residence time measurement, but it will be constant 
at each node, so the sum of errors will be constant, and the clocks will be ok?)

Please look at the new first paragraph of section 2 - there's a mix of "as 
case" and "in case" that should be made consistent. I suspect it would be 
easiest to simply say "referred to as using a one-step clock" and "referred to 
as using a two-step clock" or similar.

RjS

On 1/18/17 12:03 PM, Greg Mirsky wrote:
Hi Robert,
Sasha Vainshtein came with elegant idea to address 

Re: [Gen-art] [mpls] Review of draft-ietf-mpls-residence-time-12

[Greg Mirsky]

Hi Les,
I believe that IGP extensions to advertise RTM capability are required.

Regards,
Greg

On Thu, Jan 19, 2017 at 7:57 AM, Les Ginsberg (ginsberg)  wrote:

> Greg –
>
>
>
> I am having trouble understanding your response.
>
> The question we are raising is whether we should extend the IGPs to
> support advertising RTM capability – an alternative being to retrieve the
> capability via network management.
>
>
>
> Saying that the IGP functionality is optional and/or wouldn’t always be
> advertised doesn’t really answer the question of whether we should or
> should not define the IGP extensions.
>
>
>
> Could you respond more directly to this point?
>
>
>
>Les
>
>
>
>
>
> *From:* Greg Mirsky [mailto:gregimir...@gmail.com]
> *Sent:* Thursday, January 19, 2017 7:44 AM
> *To:* Acee Lindem (acee)
> *Cc:* Robert Sparks; m...@ietf.org; gen-art@ietf.org;
> draft-ietf-mpls-residence-time@ietf.org; i...@ietf.org; Les Ginsberg
> (ginsberg); isis-cha...@ietf.org; Abhay Roy (akr)
>
> *Subject:* Re: [mpls] Review of draft-ietf-mpls-residence-time-12
>
>
>
> Hi Acee,
>
> the draft defines optional functionality. If an operator has no use
> neither for PTP's Transparent Clock, nor RTM itself as performance metric,
> then RTM sub-TLV would not be included and thus it would not be flooded. Of
> course, it be right to reflect RTM capability through YANG data model, thus
> allowing SDN scenario you've described.
>
>
>
> Regards,
>
> Greg
>
>
>
> On Wed, Jan 18, 2017 at 2:51 PM, Acee Lindem (acee) 
> wrote:
>
> Hi Greg,
>
>
>
> Although it is a bit late, we’ve had some discussions amongst the IS-IS
> and OSPF chairs and are wondering whether the interface capability belongs
> in the IGPs. This will be flooded throughout the entire routing domain – is
> it really needed on every node or will it the RTM testing be initiated from
> an omniscient NMS client that would know the capabilities of each node or
> easily query them using YANG?
>
>
>
> Thanks,
>
> Acee
>
>
>
> *From: *mpls  on behalf of Greg Mirsky <
> gregimir...@gmail.com>
> *Date: *Wednesday, January 18, 2017 at 1:25 PM
> *To: *Robert Sparks 
> *Cc: *"m...@ietf.org" , "gen-art@ietf.org" <
> gen-art@ietf.org>, "draft-ietf-mpls-residence-time@ietf.org" <
> draft-ietf-mpls-residence-time@ietf.org>, "i...@ietf.org" <
> i...@ietf.org>
> *Subject: *Re: [mpls] Review of draft-ietf-mpls-residence-time-12
>
>
>
> Hi Robert,
>
> thank you for the most expedient review and comments. I'll make changes in
> Section 2 per your suggestion.
>
>
>
> Regards,
>
> Greg
>
>
>
> On Wed, Jan 18, 2017 at 10:34 AM, Robert Sparks 
> wrote:
>
> The changes all look good.
>
> I still think you should say something in the document about what "the
> time of packet arrival" and "transmission" means, and call out the point
> you made about being careful to not introduce apparent jitter by not making
> those measurements consistently. (The definitions you point to in your
> earlier mail from G.8013 don't really help - they just say "time of packet
> arrival". Again, the first and last bit are likely to be several
> nanoseconds apart so I think it matters. Perhaps you're saying it doesn't
> matter as long as each node is consistent (there will be error in the
> residence time measurement, but it will be constant at each node, so the
> sum of errors will be constant, and the clocks will be ok?)
>
> Please look at the new first paragraph of section 2 - there's a mix of "as
> case" and "in case" that should be made consistent. I suspect it would be
> easiest to simply say "referred to as using a one-step clock" and "referred
> to as using a two-step clock" or similar.
>
> RjS
>
>
>
> On 1/18/17 12:03 PM, Greg Mirsky wrote:
>
> Hi Robert,
>
> Sasha Vainshtein came with elegant idea to address disconnection between
> discussion of one-step and two-step modes that you've pointed out. We've
> moved Section 7 as sub-section into Section 2 now. Attached are updated
> diff and the proposed new version -13.
>
>
>
> Regards,
>
> Greg
>
>
>
> On Wed, Jan 18, 2017 at 8:13 AM, Greg Mirsky 
> wrote:
>
> Hi Robert,
>
> once again, thank you for your thorough review and the most detailed
> comments. I've prepared updated version and would greatly appreciate if you
> review the changes and let us know whether your comments been addressed.
> Attached are diff and the new version.
>
>
>
> Regards,
>
> Greg
>
>
>
> On Wed, Jan 11, 2017 at 7:48 AM, Robert Sparks 
> wrote:
>
> Reviewer: Robert Sparks
> Review result: Ready with Nits
>
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair.  Please treat these comments just
> like any other last call comments.
>
> For more information, please see the FAQ at
> 

Re: [Gen-art] [mpls] Review of draft-ietf-mpls-residence-time-12

[Les Ginsberg (ginsberg)]

Greg –

I am having trouble understanding your response.
The question we are raising is whether we should extend the IGPs to support 
advertising RTM capability – an alternative being to retrieve the capability 
via network management.

Saying that the IGP functionality is optional and/or wouldn’t always be 
advertised doesn’t really answer the question of whether we should or should 
not define the IGP extensions.

Could you respond more directly to this point?

   Les


From: Greg Mirsky [mailto:gregimir...@gmail.com]
Sent: Thursday, January 19, 2017 7:44 AM
To: Acee Lindem (acee)
Cc: Robert Sparks; m...@ietf.org; gen-art@ietf.org; 
draft-ietf-mpls-residence-time@ietf.org; i...@ietf.org; Les Ginsberg 
(ginsberg); isis-cha...@ietf.org; Abhay Roy (akr)
Subject: Re: [mpls] Review of draft-ietf-mpls-residence-time-12

Hi Acee,
the draft defines optional functionality. If an operator has no use neither for 
PTP's Transparent Clock, nor RTM itself as performance metric, then RTM sub-TLV 
would not be included and thus it would not be flooded. Of course, it be right 
to reflect RTM capability through YANG data model, thus allowing SDN scenario 
you've described.

Regards,
Greg

On Wed, Jan 18, 2017 at 2:51 PM, Acee Lindem (acee) 
> wrote:
Hi Greg,

Although it is a bit late, we’ve had some discussions amongst the IS-IS and 
OSPF chairs and are wondering whether the interface capability belongs in the 
IGPs. This will be flooded throughout the entire routing domain – is it really 
needed on every node or will it the RTM testing be initiated from an omniscient 
NMS client that would know the capabilities of each node or easily query them 
using YANG?

Thanks,
Acee

From: mpls > on behalf of 
Greg Mirsky >
Date: Wednesday, January 18, 2017 at 1:25 PM
To: Robert Sparks >
Cc: "m...@ietf.org" 
>, 
"gen-art@ietf.org" 
>, 
"draft-ietf-mpls-residence-time@ietf.org"
 
>,
 "i...@ietf.org" >
Subject: Re: [mpls] Review of draft-ietf-mpls-residence-time-12

Hi Robert,
thank you for the most expedient review and comments. I'll make changes in 
Section 2 per your suggestion.

Regards,
Greg

On Wed, Jan 18, 2017 at 10:34 AM, Robert Sparks 
> wrote:

The changes all look good.

I still think you should say something in the document about what "the time of 
packet arrival" and "transmission" means, and call out the point you made about 
being careful to not introduce apparent jitter by not making those measurements 
consistently. (The definitions you point to in your earlier mail from G.8013 
don't really help - they just say "time of packet arrival". Again, the first 
and last bit are likely to be several nanoseconds apart so I think it matters. 
Perhaps you're saying it doesn't matter as long as each node is consistent 
(there will be error in the residence time measurement, but it will be constant 
at each node, so the sum of errors will be constant, and the clocks will be ok?)

Please look at the new first paragraph of section 2 - there's a mix of "as 
case" and "in case" that should be made consistent. I suspect it would be 
easiest to simply say "referred to as using a one-step clock" and "referred to 
as using a two-step clock" or similar.

RjS

On 1/18/17 12:03 PM, Greg Mirsky wrote:
Hi Robert,
Sasha Vainshtein came with elegant idea to address disconnection between 
discussion of one-step and two-step modes that you've pointed out. We've moved 
Section 7 as sub-section into Section 2 now. Attached are updated diff and the 
proposed new version -13.

Regards,
Greg

On Wed, Jan 18, 2017 at 8:13 AM, Greg Mirsky 
> wrote:
Hi Robert,
once again, thank you for your thorough review and the most detailed comments. 
I've prepared updated version and would greatly appreciate if you review the 
changes and let us know whether your comments been addressed. Attached are diff 
and the new version.

Regards,
Greg

On Wed, Jan 11, 2017 at 7:48 AM, Robert Sparks 
> wrote:
Reviewer: Robert Sparks
Review result: Ready with Nits

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at
.

Document: 

Re: [Gen-art] [mpls] Review of draft-ietf-mpls-residence-time-12

[Greg Mirsky]

Hi Acee,
the draft defines optional functionality. If an operator has no use neither
for PTP's Transparent Clock, nor RTM itself as performance metric, then RTM
sub-TLV would not be included and thus it would not be flooded. Of course,
it be right to reflect RTM capability through YANG data model, thus
allowing SDN scenario you've described.

Regards,
Greg

On Wed, Jan 18, 2017 at 2:51 PM, Acee Lindem (acee)  wrote:

> Hi Greg,
>
> Although it is a bit late, we’ve had some discussions amongst the IS-IS
> and OSPF chairs and are wondering whether the interface capability belongs
> in the IGPs. This will be flooded throughout the entire routing domain – is
> it really needed on every node or will it the RTM testing be initiated from
> an omniscient NMS client that would know the capabilities of each node or
> easily query them using YANG?
>
> Thanks,
> Acee
>
> From: mpls  on behalf of Greg Mirsky <
> gregimir...@gmail.com>
> Date: Wednesday, January 18, 2017 at 1:25 PM
> To: Robert Sparks 
> Cc: "m...@ietf.org" , "gen-art@ietf.org" ,
> "draft-ietf-mpls-residence-time@ietf.org"  time@ietf.org>, "i...@ietf.org" 
> Subject: Re: [mpls] Review of draft-ietf-mpls-residence-time-12
>
> Hi Robert,
> thank you for the most expedient review and comments. I'll make changes in
> Section 2 per your suggestion.
>
> Regards,
> Greg
>
> On Wed, Jan 18, 2017 at 10:34 AM, Robert Sparks 
> wrote:
>
>> The changes all look good.
>>
>> I still think you should say something in the document about what "the
>> time of packet arrival" and "transmission" means, and call out the point
>> you made about being careful to not introduce apparent jitter by not making
>> those measurements consistently. (The definitions you point to in your
>> earlier mail from G.8013 don't really help - they just say "time of packet
>> arrival". Again, the first and last bit are likely to be several
>> nanoseconds apart so I think it matters. Perhaps you're saying it doesn't
>> matter as long as each node is consistent (there will be error in the
>> residence time measurement, but it will be constant at each node, so the
>> sum of errors will be constant, and the clocks will be ok?)
>>
>> Please look at the new first paragraph of section 2 - there's a mix of
>> "as case" and "in case" that should be made consistent. I suspect it would
>> be easiest to simply say "referred to as using a one-step clock" and
>> "referred to as using a two-step clock" or similar.
>>
>> RjS
>>
>> On 1/18/17 12:03 PM, Greg Mirsky wrote:
>>
>> Hi Robert,
>> Sasha Vainshtein came with elegant idea to address disconnection between
>> discussion of one-step and two-step modes that you've pointed out. We've
>> moved Section 7 as sub-section into Section 2 now. Attached are updated
>> diff and the proposed new version -13.
>>
>> Regards,
>> Greg
>>
>> On Wed, Jan 18, 2017 at 8:13 AM, Greg Mirsky 
>> wrote:
>>
>>> Hi Robert,
>>> once again, thank you for your thorough review and the most detailed
>>> comments. I've prepared updated version and would greatly appreciate if you
>>> review the changes and let us know whether your comments been addressed.
>>> Attached are diff and the new version.
>>>
>>> Regards,
>>> Greg
>>>
>>> On Wed, Jan 11, 2017 at 7:48 AM, Robert Sparks 
>>> wrote:
>>>
 Reviewer: Robert Sparks
 Review result: Ready with Nits

 I am the assigned Gen-ART reviewer for this draft. The General Area
 Review Team (Gen-ART) reviews all IETF documents being processed
 by the IESG for the IETF Chair.  Please treat these comments just
 like any other last call comments.

 For more information, please see the FAQ at
 .

 Document: draft-ietf-mpls-residence-time-12
 Reviewer: Robert Sparks
 Review Date: 2017-01-10
 IETF LC End Date: 2017-01-17
 IESG Telechat date: 2017-02-02

 Summary: Ready (with nits) for publication as a Proposed Standard

 I have two primary comments. I expect both are rooted in the authors
 and working group knowing what the document means instead of seeing
 what
 it says or doesn't say:

 1) The document is loose with its use of 'packet', and where TTLs
 appear when
 they are discussed. It might be helpful to rephrase the text that
 speaks
 of RTM packets in terms of RTM messages that are encoded as G-ACh
 messages and
 not refer to packets unless you mean the whole encapsulated packet
 with MPLS
 header, ACH, and G-ACh message.

 2) Since this new mechanic speaks in terms of fractional nanoseconds,
 some
 discussion of what trigger-point you intend people to use for taking
 the
 precise time of a packet's arrival or departure seems warranted. (The
 first and
 last 

Re: [Gen-art] Gen-ART review of draft-ietf-trill-rfc6439bis-04

[Christer Holmberg]

Hi Donald,

Please see inline.

>> Also, in general, the document does expand some acronyms on first
>> occurrence, while it does not expand others. Can the authors verify
>>that all
>> the acronyms NOT expanded so called ³well known² acronyms?
>
>Can you point to one that isn't well known?

I didn¹t check - it was more a generic question whether you have checked
the non-expanded acronyms.

But, looking in the Introduction:

1) I see that you have expanded LAN, but not VLAN. Both are well-known, so
they do not need to be enhanced.

2) LSP IS a well known acronym, and LSP actually have multiple meanings
(perhaps they all mean the same thing).

LSP- Label Switched Path (LSP) or
   - Label Switching Path (LSP) -- RARELY USED
   - Link State Packet (LSP) or
   - Link State PDU (LSP) (or Link State Protocol Data Unit)


3) FGL is not a well known acronym.

4) In the case of DRB you use the following format: 'enhanced (acronym)'.
In other cases you use 'acronym (enhanced)¹. Please be consistent whenever
you do write both the acronym and the enhanced name.

Having said that, DRB is a well known acronym, so I don¹t think you need
to enhance it. Still, as it may be a "less known well known², a reference
would still be useful.

...

>> Q4:The end of the introduction contains the following text:
>>
>> ³This documents obsoletes [RFC6439], updates [RFC6325], and updates
>> [RFC7177], as described in Appendix B.²
>>
>> That¹s all good, but I think it would be good to have a few words also
>>in
>> the Introduction, explaining exactly what is obsoleted and updated.
>
>OK, especially as it is more like it incorporates RFC 6439 to simplify
>things and reduce the number of documents that implementers have to
>look at.


That is also very good information. The details can be in Appendix B, but
I think it would be good to have a high-level description in the
Introduction.


>> Q5:The end of the introduction contains the following text:
>>
>> ³It also includes reference implementation details.
>>   Alternative implementations that interoperate on the wire
>>are
>>   permitted.²
>>
>> Is the last sentence really needed? I don¹t think an RFC can mandate the
>> usage of one specific implementation of the RFC.
>
>Well, I think the TRILL WG likes wording similar to that. It also
>occurs in at least RFC 6325, the TRILL base protocol specification.

Ok. I won¹t argue against it, I just think it sounds a little strange :)

But, could you then add a reference to the section describing the
reference implementation details, because I don¹t think it is explicit
anywhere.

Also, if the reference implementation details are different from the ones
in 6325 I think it would be useful to point out.

Regards,

Christer

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen-ART Telechat Call review of draft-ietf-rtgwg-rlfa-node-protection-10

[Pushpasis Sarkar]

Hi Meral,

Thanks a lot for your review once again.

Regards,
-Pushpasis

On Thu, Jan 19, 2017 at 12:14 AM, Meral Shirazipour <
meral.shirazip...@ericsson.com> wrote:

> I am the assigned Gen-ART reviewer for this draft. The General Area Review
> Team (Gen-ART) reviews all IETF documents being processed by the IESG for
> the IETF Chair. Please wait for direction from your document shepherd or AD
> before posting a new version of the draft.
>
>
>
> For more information, please see the FAQ at  area/gen/trac/wiki/GenArtfaq>.
>
>
>
> Document: draft-ietf-rtgwg-rlfa-node-protection-10
>
> Reviewer: Meral Shirazipour
>
> Review Date: 2017-01-18
>
> IETF LC End Date: 2017-01-04 (extension 2017-01-11)
>
> IESG Telechat date: 2017-01-05  (extension 2017-01-19)
>
>
>
> Summary: This draft is ready to be published as Standards RFC.
>
>
>
> Major issues:
>
> Minor issues:
>
> Nits/editorial comments:
>
>
>
>
>
> Best Regards,
>
> Meral
>
> ---
>
> Meral Shirazipour
>
> Ericsson Research
>
> www.ericsson.com
>
>
>
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Review of draft-ietf-nvo3-use-case-15

[Jari Arkko]

Thanks for the review, Ralph, and for taking care of the edits, Lucy!

Jari

On 06 Jan 2017, at 17:46, Lucy yong  wrote:

> Hi Ralph,
> 
> Thank you for the review. We will have all acronyms expansion in next version 
> and add a reference for DC services.
> 
> Regards,
> Lucy
> 
> -Original Message-
> From: Gen-art [mailto:gen-art-boun...@ietf.org] On Behalf Of Ralph Droms
> Sent: Friday, January 06, 2017 7:14 AM
> To: gen-art@ietf.org
> Cc: n...@ietf.org; draft-ietf-nvo3-use-case@ietf.org; i...@ietf.org
> Subject: [Gen-art] Review of draft-ietf-nvo3-use-case-15
> 
> Reviewer: Ralph Droms
> Review result: Ready with Nits
> 
> I am the assigned Gen-ART reviewer for this draft. The General Area Review 
> Team (Gen-ART) reviews all IETF documents being processed by the IESG for the 
> IETF Chair.  Please treat these comments just like any other last call 
> comments.
> 
> For more information, please see the FAQ at
> 
> .
> 
> Document: draft-ietf-nvo3-use-case-??
> Reviewer: Ralph Droms
> Review Date: 2017-01-06
> IETF LC End Date: 2017-01-11
> IESG Telechat date: 2017-01-19
> 
> Summary: This draft is ready for publication as an Informational RFC.
> 
> Major issues: None
> 
> Minor issues: None
> 
> Nits/editorial comments:
> 
> I found several acronyms that did not have expansions.  I recommend a pass 
> over the document for unexpanded acronyms..
> 
> Section 2: What is "broadcast/unknown" traffic (spec. "unknown"?); please 
> expand the acronym "BUM".
>  The paragraph that begins with "One NVO3 network [...]" is indented 
> differently from the rest of the text.  Intentional or a typo?
> 
> Section 3.2: An illustrating figure for the use case described in this 
> section would be helpful.
>  Expand acronyms "PE" and "ABSR".
>  I found the text using "Option A" and "Option B" confusing.  Exactly what 
> are those options?
> 
> Section 5: I didn't understand the references to IaaS, PaaS and SaaS in the 
> summary - there are no references to those services in the body of the 
> document, or back pointers from the summary to relevant preceding text.
> 
> ___
> Gen-art mailing list
> Gen-art@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art
> 



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Review of draft-ietf-sidr-adverse-actions-03

[Jari Arkko]

Many thanks again for the review, Dan. Thanks for the explanation re: the 
title, Steve — I was also wondering about it at first.

I have posted a no-objection position for this document in tonight’s IESG 
telechat.

Jari



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] draft-murchison-webdav-prefer-13

[Jari Arkko]

FYI I posted a no-objection vote for this document in tonight’s IESG telechat.

Jari



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] draft-murchison-webdav-prefer-13

[Jari Arkko]

Thanks Ken and Stewart!

Jari



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen-ART Last Call review of draft-ietf-i2rs-yang-l3-topology-08

[Jari Arkko]

Thanks for your review, Paul.

Authors, have you seen these comments? Didn’t see a response.

From my perspective "unnumbered" is still ok — we’ve traditionally called 
unnumbered interfaces such interfaces that have no address. But they typically 
would still have ifIndexes etc. But maybe some additional words to explain 
might be useful?

Jari

On 13 Jan 2017, at 21:50, Paul Kyzivat  wrote:

> I am the assigned Gen-ART reviewer for this draft. The General Area Review 
> Team (Gen-ART) reviews all IETF documents being processed by the IESG for the 
> IETF Chair. Please treat these comments just like any other last call 
> comments. For more information, please see the FAQ at 
> <​http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
> 
> Document: draft-ietf-i2rs-yang-l3-topology-08
> Reviewer: Paul Kyzivat
> Review Date: 2017-01-13
> IETF LC End Date: 2017-01-17
> IESG Telechat date:
> 
> Summary:
> 
> This draft is on the right track but has open issues, described in the review.
> 
> Disclaimer:
> 
> I started this review without any knowledge of YANG modeling. So the sort of 
> review I can do is superficial.
> 
> Issues:
> 
> Major: 0
> Minor: 2
> Nits:  1
> 
> (1) Minor:
> 
> In sections 4 & 5, one of the termination-point-types is called "unnumbered", 
> and contains an "unnumbered-id". But the value contained here is in fact a 
> uint32 *index* value. This clearly *is* a number. So, ISTM that "unnumbered" 
> is a misleading name for this element.
> 
> I gather it designates a termination point that is identified by this index 
> rather than by a name or an ip-address. If so, a better name might be "index" 
> or "indexed".
> 
> (2) Minor:
> 
> The examples in section 6.2 seem very helpful. But is it really necessary to 
> fill in so much detail? The amount of detail seems to make it overly 
> difficult to grasp the essential features. For instance, the contact and 
> description information could be shortened.
> 
> (3) NIT:
> 
> In section 1, s/augments general network/augments the general network/
> 
> ___
> Gen-art mailing list
> Gen-art@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen-ART Telechat Call review of draft-ietf-rtgwg-rlfa-node-protection-10

[Jari Arkko]

Thanks again for your review, Meral.

Jari



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art