Re: [mpls] Progressing Residence Time Measurement draft

[<[e-mail]>]

Hi Sasha,

Thanks for your summary.

It would indeed be good if you could look at how the solution applies to SR networks.

Based on your very short summary, I would a priori assume that mainly the point 4 would need to be adapted. Looks a priori doable, but obviously it’s easier when you don’t look at the details (my case) ;-).

On a side note, for IGP signaling, I understand that you need to advertise RTM capability on a per adjacency basis. It’s not a priori obvious to me how you achieve this for IS-IS. (but again, I haven’t looked in details).

Thanks,
Regards,
-- Bruno

From: Alexander Vainshtein [mailto:[e-mail]]
Sent: Monday, February 01, 2016 10:03 AM
To: DECRAENE Bruno IMT/OLN
Cc: [e-mail]; Lou Berger; [e-mail]
Subject: RE: [mpls] Progressing Residence Time Measurement draft


Bruno,

Lots of thanks for your interest in the RTM draft (even if you have not read it☺).



As I see it:



1.       RTM capabilities are per physical interface and include:

o   Minimal: ability to associate the timestamp to a received/transmitted packet

o   One-step RTM: ability to update the accumulated residence time value in the scratch pad of the packet as it is transmitted to the network.

2.       If different ports of you router have different RTM capabilities, you must take that into account when you select your TE path.

3.       LAG between ports with different RTM capabilities should be treated as having the minimal capability of all comprising ports.

4.       RTM uses TTL expiration augmented by presence of GAL at the bottom of the label stack with a specific G-ACH channel type to trigger RTM processing, so any loose paths between TE nodes are highly problematic for it.



Hope this helps.



Regards,

Sasha



Office: [phone]

Cell:      [phone]

Email:   [e-mail]



-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
Sent: Monday, February 01, 2016 10:32 AM
To: Lou Berger; Alexander Vainshtein; [e-mail]
Cc: [e-mail]
Subject: RE: [mpls] Progressing Residence Time Measurement draft



Lou, Sasha,



> From: mpls [mailto:[e-mail]] On Behalf Of Lou Berger

> Sent: Sunday, January 31, 2016 4:08 PM

>

> Sasha,

>     See below.

>

> On 1/31/2016 9:50 AM, Alexander Vainshtein wrote:

> > Lou,

> > First of all, lots of thanks for the comments - both for ones you

> > have sent

> and - in advance - for one dealing with RSVP-TE that you've promised

> to send.

> >

> > Second, I wonder which TE LSPs beyond ones set up by RSVP-TE ones

> > you

> have in mind.

> >

> > If  you are speaking about statically configured LSPs (and these, in

> > a way,

> are always TE LSPs), I do not foresee any problem with extending RTM

> to them.

> Yes.  Or controller based.

>

> > If, however, you are speaking about LSPs that have been set up using

> Segment Routing (SR), I doubt RTM can work with these because these

> LSPs could (and, most probably, probably would) include multiple ECMP

> sub-paths between specific "pinned" nodes.

> Haven't really dug in enough on SR to have an opinion...



Lou, thanks for the comment.



SR allows for strictly routed packets (at the cost of stacking one label per hop on the way).

BTW what do you mean exactly by ECMP?

- does parallel IP interfaces between 2 nodes count as ECMP/is an issue? (note that SR can allow both load balancing over those parallel interfaces or selecting a specific one. The former is not option that may not be implemented. The latter is a must.)

- does parallel layer 2 interfaces (e.g. Ethernet LAG) within one IP interfaces between 2 nodes count as ECMP/is an issue? (as of today, SR only provides load-balancing as the IP layer only see 1 interface. draft-ginsberg-isis-l2bundles could address this)



Note that I've not read the draft. But a priori, it would be good if it could be made generic enough to cover SR (possibly in an another draft)



Thanks,

-- Bruno



> > So I am not sure extending (even at the level of a declaration

> > without

> providing any details) applicability of RTP to all TE LSPs is the

> right way to go.

>

> I think the fully pinned/ER case should be covered -- and that's what

> I was really trying to refer to.

>

> Thanks,

> Lou

>

> > Regards,

> > Sasha

> >

> > Office: [phone]

> > Cell:      [phone]

> > Email:   [e-mail]<mailto:[e-mail]>

> >

> > -----Original Message-----

> > From: Lou Berger [mailto:[e-mail]]

> > Sent: Sunday, January 31, 2016 4:27 PM

> > To: Acee Lindem (acee); Gregory Mirsky; Loa Andersson;

> > draft-ietf-mpls-

> [e-mail]<mailto:[e-mail]>

> > Cc: [e-mail]<mailto:[e-mail]>

> > Subject: Re: [mpls] Progressing Resdience Time Measurement draft

> >

> > So this thread triggered me to reread the draft.  I don't really

> > have any

> time sync experience, so won't be commenting on those aspects of the

> draft

> - but I did just send a message off to the DetNet WG as they be

> interested in using this at some point and are likely to have some

> folks with 1588 knowledge.

> >

> > The following comment is independent of which LSA types are used, as

> discussed below, but others may feel it impacts the choice.

> >

> > Should the solution really scoped to just RSVP controlled TE LSPs?

> > It

> seems to me it should work for any TE LSP, and any TE LSP setup

> mechanism that can provide the participating nodes with the required

> information.  Does this make sense?

> >

> > I think the following changes are one way to make this change:

> > OLD

> >

> >     The scope of

> >    this document is on LSPs instantiated using RSVP-TE [RFC3209

> <https://tools.ietf.org/html/rfc3209>] because

> >    the LSP's path can be determined.

> > NEW

> >

> >     The scope of this document is on TE LSPs, e.g., those  instantiated using

> >      RSVP-TE [RFC3209 <https://tools.ietf.org/html/rfc3209>],

> > because the

> LSP's path can be determined.

> >

> > And add text that describes the following in a new section, perhaps

> > at

> > 4.6 or 4.8 "Non-RSVP controlled LSPs"

> >   When the TE LSP is controlled via mechanisms other than RSVP-TE,

> > the

> following information needs to be provided to the RTM capable nodes

> along the LSP path:

> >    - RTM role (ingress, transit, egress)

> >    - RTM neighbors

> >    - RTM hop counts (as needed)

> >   - Anything else I'm sure I missed!

> >   The method used to convey this information is out of scope of this

> document.

> >

> > I have an RSVP specific comment that I'll send separately.

> >

> > Thanks,

> > Lou

> >

> > PS I think this is important work and hope to see it completed soon.

> >

> > On 1/31/2016 7:50 AM, Acee Lindem (acee) wrote:

> >> Hi Greg,

> >> That sounds like a good plan.

> >> Thanks,

> >> Acee

> >>

> >> On 1/30/16, 8:36 PM, "Gregory Mirsky" <[e-mail]<mailto:[e-mail]>>

> wrote:

> >>

> >>> Hi Acee,

> >>> thank you for your thorough review and OSPF insights.

> >>> I've updated reference to RFC 7684 in the new -01 version.

> >>> When we were starting work on RTM we intended to address LDP

> signaled

> >>> IP/MPLS networks as well and that, as I recall, was the reason to

> >>> use more generic IGP TLVs rather than TE-specific. Since LDP

> >>> drifted out of scope, I agree, use of TE advertisements is more

> >>> suitable. We'll work on that and share new update with you and the IGP WGs.

> >>>

> >>>    Regards,

> >>>                    Greg

> >>>

> >>> -----Original Message-----

> >>> From: mpls [mailto:[e-mail]] On Behalf Of Acee Lindem

> >>> (acee)

> >>> Sent: Thursday, January 28, 2016 4:55 PM

> >>> To: Loa Andersson

> >>> Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>

> >>> Subject: Re: [mpls] Progressing Resdience Time Measurement draft

> >>>

> >>> I’ve read the subject draft and think it offers a useful function

> >>> to facilitate more accurate time synchronization in NTP/PTP deployments.

> >>> One question I have is why the capability is signaled in the

> >>> generic IGP TLV LSAs and LSPs rather than the TE advertisements

> >>> when the document is scoped to RSVP-TE [RFC3209] LSPs? One reason

> >>> I ask is that we are waiting on implementations of the OSPFv3

> >>> Extended LSAs draft. Having said that,

> >>> OSPFv2 and OSPFv3 have separate registry for the TLV LSAs and

> >>> section

> >>> 8 should reflect this. Also, OSPF Prefix/Link Attributes is now RFC 7684.

> >>>

> >>> Thanks,

> >>> Acee

> >>>> -----Original Message-----

> >>>> From: Loa Andersson [mailto:[e-mail]]

> >>>> Sent: Monday, December 14, 2015 7:23 PM

> >>>> To: Gregory Mirsky; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>

> >>>> Cc: [e-mail]<mailto:[e-mail]>

> >>>> Subject: Re: [mpls] Progressing Resdience Time Measurement draft

> >>>> Working Group and authors, <chair hat off> As a matter of fact I

> >>>> believe this document should be progressed.

> >>>> <chair hat on>

> >>>> This draft has been a working group document since early August,

> >>>> but there has been no discussion on the document on the wg mailing list.

> >>>> There are of course two ways if interpreting this.

> >>>> - there is total agreement on the draft

> >>>> - there is no intrest in the draft I have no basis to decide

> >>>> which is the case.

> >>>> Can we plese have at least a few (non-author) comments on the

> >>>> mailing list if it is time to start the wglc.

> >>>> /Loa

> >>>> mpls wg co-chair

> >>>> On 2015-12-15 07:21, Gregory Mirsky wrote:

> >>>> Dear Chairs of the MPLS WG,

> >>>>> authors of the Residence Time Measurement in MPLS Network draft

> >>>>> believe that all comments received during the WG adoption call

> >>>>> been addressed.

> >>>>> Thus, authors would like to ask the WG Chairs to consider WG LC

> >>>>> as the next step.

> >>>>>                 Regards,

> >>>>>                                 Greg

> >>>>> _______________________________________________

> >>>>> mpls mailing list

> >>>>> [e-mail]<mailto:[e-mail]>

> >>>>> https://www.ietf.org/mailman/listinfo/mpls

> >>> _______________________________________________

> >>> mpls mailing list

> >>> [e-mail]<mailto:[e-mail]>

> >>> https://www.ietf.org/mailman/listinfo/mpls

> >> _______________________________________________

> >> mpls mailing list

> >> [e-mail]<mailto:[e-mail]>

> >> https://www.ietf.org/mailman/listinfo/mpls

> >

>

>

> _______________________________________________

> mpls mailing list

> [e-mail]<mailto:[e-mail]>

> https://www.ietf.org/mailman/listinfo/mpls



_________________________________________________________________________________________________________________________



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



This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.

Thank you.



_________________________________________________________________________________________________________________________

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

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