Subject: [Teas] I-D Action: draft-ietf-teas-rsvp-te-srlg-collect-05.txt

From: [email-masked]
Date: Mon, 04 Apr 2016 10:26:11 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Traffic Engineering Architecture and Signaling of the IETF.

        Title           : RSVP-TE Extensions for Collecting SRLG Information
        Authors         : Fatai Zhang
                          Oscar Gonzalez de Dios
                          Matt Hartley
                          Zafar Ali
                          Cyril Margaria
	Filename        : draft-ietf-teas-rsvp-te-srlg-collect-05.txt
	Pages           : 15
	Date            : 2016-04-04

Abstract:
   This document provides extensions for the Resource ReserVation
   Protocol-Traffic Engineering (RSVP-TE), including GMPLS, to support
   automatic collection of Shared Risk Link Group (SRLG) information for
   the TE link formed by a Label Switched Path (LSP).

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-teas-rsvp-te-srlg-collect/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-teas-rsvp-te-srlg-collect-05

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-teas-rsvp-te-srlg-collect-05

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: "Matt Hartley (mhartley)" <[email-masked]>
Date: Mon, 4 Apr 2016 17:30:05 +0000

All,

A minor update to fix a bit of the signaling overview that was inconsistent with the rest of the document.

Cheers

Matt

> Please note that it may take a couple of minutes from the time of
> submission until the htmlized version and diff are available at
> tools.ietf.org.
> 
> _______________________________________________
> Teas mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/teas

---

From: "Matt Hartley (mhartley)" <[email-masked]>
Date: Mon, 4 Apr 2016 18:06:38 +0000

Himanshu,

> Question on your presentation today -
> 
> You mentioned that transit LSRs can participate full, subset or no SRLG
> based on the local policy (hope I understood this correctly). 

Yes.

> When that is
> the case, does it provide indication to the head-end that collected SRLG
> list is not complete?

No, it doesn't. Earlier versions of the draft did include this capability, but after some debate the conclusion was that the additional complexity/complication wasn't worthwhile, and so it was removed. A node that isn't providing complete SRLG data for policy reasons may also not wish to announce the fact.

Cheers

Matt

> 
> Thanks,
> Himanshu
> 
> -----Original Message-----
> From: Teas [mailto:[email-masked]] On Behalf Of Matt Hartley
> (mhartley)
> Sent: Monday, April 04, 2016 1:30 PM
> To: [email-masked]; [email-masked]
> Cc: Matt Hartley (mhartley); [email-masked]
> Subject: Re: [Teas] I-D Action: draft-ietf-teas-rsvp-te-srlg-collect-
> 05.txt
> 
> All,
> 
> A minor update to fix a bit of the signaling overview that was
> inconsistent with the rest of the document.
> 
> Cheers
> 
> Matt
> 
> >

---

From: "Shah, Himanshu" <[email-masked]>
Date: Mon, 4 Apr 2016 14:10:52 -0400

Thanks - Do you think a global bit (not specific to a hop), that indicates partial list
and not identify the specific LSR(s) would be useful?
 
Thanks,
Himanshu

-----Original Message-----
From: Matt Hartley (mhartley) [mailto:[email-masked]] 
Sent: Monday, April 04, 2016 2:07 PM
To: Shah, Himanshu
Cc: [email-masked]; Matt Hartley (mhartley)
Subject: RE: [Teas] I-D Action: draft-ietf-teas-rsvp-te-srlg-collect-05.txt

Himanshu,

> You mentioned that transit LSRs can participate full, subset or no 
> SRLG based on the local policy (hope I understood this correctly).

Yes.

> When that is
> the case, does it provide indication to the head-end that collected 
> SRLG list is not complete?

Cheers

Matt

> > https://www.ietf.org/rfcdiff?url2=draft-ietf-teas-rsvp-te-srlg-colle
> > ct
> > -05
> >
> >

---

From: "Shah, Himanshu" <[email-masked]>
Date: Mon, 4 Apr 2016 14:00:23 -0400

You mentioned that transit LSRs can participate full, subset or no SRLG based on the local policy
(hope I understood this correctly). When that is the case, does it provide indication to the head-end
that collected SRLG list is not complete?

Thanks,
Himanshu

-----Original Message-----
From: Teas [mailto:[email-masked]] On Behalf Of Matt Hartley (mhartley)
Sent: Monday, April 04, 2016 1:30 PM
To: [email-masked]; [email-masked]
Cc: Matt Hartley (mhartley); [email-masked]
Subject: Re: [Teas] I-D Action: draft-ietf-teas-rsvp-te-srlg-collect-05.txt

All,

Cheers

Matt

---

From: "Matt Hartley (mhartley)" <[email-masked]>
Date: Tue, 5 Apr 2016 17:39:25 +0000

Himanshu,

> Thanks - Do you think a global bit (not specific to a hop), that indicates
> partial list and not identify the specific LSR(s) would be useful?

I'm not sure that this was ever discussed much, but my feeling is that it isn't. A node which doesn't wish to announce that it's withholding SRLG information for its hop probably won't want to do so globally either. And I'm not sure what an endpoint would do with the information in any case; you can make decisions based on the information you have even if that information is limited, but knowing that it's incomplete doesn't help you much.

Cheers

Matt

> No, it doesn't. Earlier versions of the draft did include this capability,
> but after some debate the conclusion was that the additional
> complexity/complication wasn't worthwhile, and so it was removed. A node
> that isn't providing complete SRLG data for policy reasons may also not
> wish to announce the fact.
> 
> Cheers
> 
> Matt
> 
> >
> > Thanks,
> > Himanshu
> >

---

From: "Shah, Himanshu" <[email-masked]>
Date: Tue, 5 Apr 2016 14:01:20 -0400

Only for the sake of operator/user information that SRLG strict diverse may not necessarily be strictly diverse
because of incomplete collected information.

I agree there is no corrective action for head-end.. 

Thanks,
Himanshu

-----Original Message-----
From: Matt Hartley (mhartley) [mailto:[email-masked]] 
Sent: Tuesday, April 05, 2016 1:39 PM
To: Shah, Himanshu
Cc: [email-masked]; Matt Hartley (mhartley)
Subject: RE: [Teas] I-D Action: draft-ietf-teas-rsvp-te-srlg-collect-05.txt

Himanshu,

> Thanks - Do you think a global bit (not specific to a hop), that 
> indicates partial list and not identify the specific LSR(s) would be useful?

Cheers

Matt

> No, it doesn't. Earlier versions of the draft did include this 
> capability, but after some debate the conclusion was that the 
> additional complexity/complication wasn't worthwhile, and so it was 
> removed. A node that isn't providing complete SRLG data for policy 
> reasons may also not wish to announce the fact.
> 
> Cheers
> 
> Matt
> 
> >
> > Thanks,
> > Himanshu
> >
> > >    automatic collection of Shared Risk Link Group (SRLG) 
> > > information
> for
> > > https://datatracker.ietf.org/doc/draft-ietf-teas-rsvp-te-srlg-coll
> > > ec
> > > t/
> > >

---

From: "Matt Hartley (mhartley)" <[email-masked]>
Date: Thu, 7 Apr 2016 15:24:12 +0000

Himanshu,

> Only for the sake of operator/user information that SRLG strict diverse
> may not necessarily be strictly diverse because of incomplete collected
> information.

But in cases like this I'd have thought that the operators would already be aware of what information will and won't traverse the PE/CE boundary as there would be some sort of contract/agreement on that.

> I agree there is no corrective action for head-end..

Yep. And if there's nothing the endpoint can do then I don't really see much benefit in the additional complexity of adding that information to the signaled objects.

Cheers

Matt

> I'm not sure that this was ever discussed much, but my feeling is that it
> isn't. A node which doesn't wish to announce that it's withholding SRLG
> information for its hop probably won't want to do so globally either. And
> I'm not sure what an endpoint would do with the information in any case;
> you can make decisions based on the information you have even if that
> information is limited, but knowing that it's incomplete doesn't help you
> much.
> 
> Cheers
> 
> Matt
> 
> >
> > Thanks,
> > Himanshu
> >
> >

---

From: "Shah, Himanshu" <[email-masked]>
Date: Thu, 7 Apr 2016 11:37:53 -0400

Hi Matt -

I still believe there is utility in obtaining this information for the operator, even when he
may have set SRLG-non-disclose policy for a given node within one area or other area across ABR.

Here is the reason why I think this is true.
If LSPs are dynamically signaled operator may not proactively know what path a specific LSP would
take as it is based on TE requirements of the LSP and current resource availability state of the network.

So it would be important which 1:1 linear protected LSPs are strictly diverse and which may not be
strictly diverse based on the fact that primary happens to transit through one of those nodes.

Second point - I don't think that it is complex for a node to set a bit in a flag field, and
head-end to record.

This is my suggestion. I would like to hear from other WG member to opine (especially an operator)
on this as well. 

However, if WG does not feel this to be important, so be it - no worries.

Thanks,
Himanshu

-----Original Message-----
From: Matt Hartley (mhartley) [mailto:[email-masked]] 
Sent: Thursday, April 07, 2016 11:24 AM
To: Shah, Himanshu
Cc: [email-masked]; Matt Hartley (mhartley)
Subject: RE: [Teas] I-D Action: draft-ietf-teas-rsvp-te-srlg-collect-05.txt

Himanshu,

> Only for the sake of operator/user information that SRLG strict 
> diverse may not necessarily be strictly diverse because of incomplete 
> collected information.

Cheers

Matt

> I'm not sure that this was ever discussed much, but my feeling is that 
> it isn't. A node which doesn't wish to announce that it's withholding 
> SRLG information for its hop probably won't want to do so globally 
> either. And I'm not sure what an endpoint would do with the 
> information in any case; you can make decisions based on the 
> information you have even if that information is limited, but knowing 
> that it's incomplete doesn't help you much.
> 
> Cheers
> 
> Matt
> 
> >
> > Thanks,
> > Himanshu
> >
> >
> > Subject: RE: [Teas] I-D Action: 
> > draft-ietf-teas-rsvp-te-srlg-collect-
> > 05.txt
> >
> > Himanshu,
> >
> > > the case, does it provide indication to the head-end that 
> > > collected SRLG list is not complete?
> >
> > > > https://tools.ietf.org/html/draft-ietf-teas-rsvp-te-srlg-collect
> > > > -0
> > > > 5
> > > >
> > > > https://www.ietf.org/rfcdiff?url2=draft-ietf-teas-rsvp-te-srlg-c
> > > > ol
> > > > le
> > > > ct
> > > > -05
> > > >
> > > >
> > > > Please note that it may take a couple of minutes from the time 
> > > > of submission until the htmlized version and diff are available 
> > > > at tools.ietf.org.
> > > >

---

From: Phil Bedard <[email-masked]>
Date: Thu, 07 Apr 2016 13:27:50 -0400

If I understand the draft correctly, you would end up with a RRO with no SRLG attribute set for the hop not disclosing SRLG information.  I think the policy of the head-end node would be the same whether it ran into a node not supporting the SRLG extensions or one not disclosing them through administrative policy.   

Phil

---

From: "Zafar Ali (zali)" <[email-masked]>
Date: Thu, 7 Apr 2016 17:49:11 +0000

Phil- 

You may have a RRO hop with no SRLG if the reporting node does not
implement the recording or because there was no shared risk at that hop.
So implying in this way is not viable, IMO.

Thanks

Regards Š Zafar

On 4/7/16, 1:27 PM, "Teas on behalf of Phil Bedard" <[email-masked]
on behalf of [email-masked]> wrote:

>If I understand the draft correctly, you would end up with a RRO with no
>SRLG attribute set for the hop not disclosing SRLG information.  I think
>the policy of the head-end node would be the same whether it ran into a
>node not supporting the SRLG extensions or one not disclosing them
>through administrative policy.
>
>Phil 
>
>
>Subject: Re: [Teas] I-D Action:
>draft-ietf-teas-rsvp-te-srlg-collect-05.txt
>
>>Hi Matt -
>>
>>draft-ietf-teas-rsvp-te-srlg-collect-05.txt
>>
>>Himanshu,
>>
>>But in cases like this I'd have thought that the operators would already
>>be aware of what information will and won't traverse the PE/CE boundary
>>as there would be some sort of contract/agreement on that.
>>
>>Yep. And if there's nothing the endpoint can do then I don't really see
>>much benefit in the additional complexity of adding that information to
>>the signaled objects.
>>
>>Cheers
>>
>>Matt
>>
>>> 
>>> Thanks,
>>> Himanshu
>>>

---

From: Dieter Beller <[email-masked]>
Date: Thu, 7 Apr 2016 20:04:42 +0200

Hi Matt,Himanshu, all,

I tend to concur with Himanshu. A flag indicating whether the collected 
SRLG information is complete or incomplete could be useful for an operator.

If the SRLG information is incomplete, there is a chance that 2 LSPs 
aren't fully SRLG diverse, which are intended to be fully diverse. If 
such a flag
exists, the operator could at least take specific actions to check the 
diversity of those LSPs tha have an incomplete SRLG list.

Thanks,
Dieter

---

From: "Matt Hartley (mhartley)" <[email-masked]>
Date: Thu, 7 Apr 2016 18:58:17 +0000

This depends on how the head-end makes the SRLG-collection request.

If it's in a LSP_REQUIRED_ATTRIBUTES object, then any node that doesn't understand the request will send a Path-Error back to the head. That means that if signaling is successful, you can guarantee that every transit node at least received and understood the SRLG-collection request. You still don't know whether a node that announced no SRLGs did so because it has none, or because its policy is not to announce them.

If the request was made in a LSP_ATTRIBUTES object, the above still applies, but there exists also the possibility that a node simply didn't understand the collection request.

Cheers

Matt

> >If I understand the draft correctly, you would end up with a RRO with
> >no SRLG attribute set for the hop not disclosing SRLG information.  I
> >think the policy of the head-end node would be the same whether it ran
> >into a node not supporting the SRLG extensions or one not disclosing
> >them through administrative policy.
> >
> >Phil
> >
> >
> >>I still believe there is utility in obtaining this information for the
> >>operator, even when he may have set SRLG-non-disclose policy for a
> >>given node within one area or other area across ABR.
> >>
> >>If LSPs are dynamically signaled operator may not proactively know
> >>what path a specific LSP would take as it is based on TE requirements
> >>of the LSP and current resource availability state of the network.
> >>
> >>So it would be important which 1:1 linear protected LSPs are strictly
> >>diverse and which may not be strictly diverse based on the fact that
> >>primary happens to transit through one of those nodes.
> >>
> >>Second point - I don't think that it is complex for a node to set a
> >>bit in a flag field, and head-end to record.
> >>
> >>This is my suggestion. I would like to hear from other WG member to
> >>opine (especially an operator) on this as well.
> >>
> >>> diverse may not necessarily be strictly diverse because of
> >>> incomplete collected information.
> >>
> >>But in cases like this I'd have thought that the operators would
> >>already be aware of what information will and won't traverse the PE/CE
> >>boundary as there would be some sort of contract/agreement on that.
> >>
> >>Yep. And if there's nothing the endpoint can do then I don't really
> >>see much benefit in the additional complexity of adding that
> >>information to the signaled objects.
> >>
> >>Cheers
> >>
> >>Matt
> >>
> >>>
> >>> Thanks,
> >>> Himanshu
> >>>
> >>> > indicates partial list and not identify the specific LSR(s) would
> >>> > be
> >>> useful?
> >>>
> >>> I'm not sure that this was ever discussed much, but my feeling is
> >>> that it isn't. A node which doesn't wish to announce that it's
> >>> withholding SRLG information for its hop probably won't want to do
> >>> so globally either. And I'm not sure what an endpoint would do with
> >>> the information in any case; you can make decisions based on the
> >>> information you have even if that information is limited, but
> >>> knowing that it's incomplete doesn't help you much.
> >>>
> >>> Cheers
> >>>
> >>> Matt
> >>>
> >>> >
> >>> > Thanks,
> >>> > Himanshu
> >>> >
> >>> >
> >>> > > You mentioned that transit LSRs can participate full, subset or
> >>> > > no SRLG based on the local policy (hope I understood this
> correctly).
> >>> >
> >>> > Yes.
> >>> >
> >>> > > When that is
> >>> > additional complexity/complication wasn't worthwhile, and so it
> >>> > was removed. A node that isn't providing complete SRLG data for
> >>> > policy reasons may also not wish to announce the fact.
> >>> >
> >>> > Cheers
> >>> >
> >>> > Matt
> >>> >
> >>> > >
> >>> > > Thanks,
> >>> > > Himanshu
> >>> > >
> >>> > > > https://datatracker.ietf.org/doc/draft-ietf-teas-rsvp-te-srlg-
> >>> > > > co
> >>> > > > ll
> >>> > > > ec
> >>> > > > t/
> >>> > > >
> >>> > > > of submission until the htmlized version and diff are
> >>> > > > available at tools.ietf.org.
> >>> > > >

---

From: "Zafar Ali (zali)" <[email-masked]>
Date: Thu, 7 Apr 2016 19:02:17 +0000

Hi- 

Yes, we are on the same page. I.e., implying by looking at the SRLG
recorded values in RRO hop is not viable.

Thanks

Regards ... Zafar 

On 4/7/16, 2:58 PM, "Matt Hartley (mhartley)" <[email-masked]> wrote:

>If it's in a LSP_REQUIRED_ATTRIBUTES object, then any node that doesn't
>understand the request will send a Path-Error back to the head. That
>means that if signaling is successful, you can guarantee that every
>transit node at least received and understood the SRLG-collection
>request. You still don't know whether a node that announced no SRLGs did
>so because it has none, or because its policy is not to announce them.
>
>If the request was made in a LSP_ATTRIBUTES object, the above still
>applies, but there exists also the possibility that a node simply didn't
>understand the collection request.
>
>Cheers
>
>Matt
>
>> Phil-
>> 
>> >>> > > >         Title           : RSVP-TE Extensions for Collecting
>>SRLG
>> >>> > > > Information
>> >>> > > >         Authors         : Fatai Zhang
>> >>> > > >                           Oscar Gonzalez de Dios
>> >>> > > >                           Matt Hartley
>> >>> > > >                           Zafar Ali
>> >>> > > >                           Cyril Margaria

---

From: Fatai Zhang <[email-masked]>
Date: Thu, 7 Apr 2016 19:04:25 +0000

Hi all,

+1. 

I think it might be useful in the multi-domain scenarios. 

Thanks

Fatai

-----邮件原件-----
发件人: Teas [mailto:[email-masked]] 代表 Dieter Beller
发送时间: 2016年4月8日 2:05
收件人: EXT Shah, Himanshu; Matt Hartley (mhartley)
抄送: [email-masked]
主题: Re: [Teas] I-D Action: draft-ietf-teas-rsvp-te-srlg-collect-05.txt

Hi Matt,Himanshu, all,

I tend to concur with Himanshu. A flag indicating whether the collected SRLG information is complete or incomplete could be useful for an operator.

If the SRLG information is incomplete, there is a chance that 2 LSPs aren't fully SRLG diverse, which are intended to be fully diverse. If such a flag exists, the operator could at least take specific actions to check the diversity of those LSPs tha have an incomplete SRLG list.

Thanks,
Dieter

On 07.04.2016 17:37, EXT Shah, Himanshu wrote:
> operator, even when he may have set SRLG-non-disclose policy for a given node within one area or other area across ABR.
>
> what path a specific LSP would take as it is based on TE requirements of the LSP and current resource availability state of the network.
>
> diverse and which may not be strictly diverse based on the fact that primary happens to transit through one of those nodes.
>
>> withholding SRLG information for its hop probably won't want to do so 
>> globally either. And I'm not sure what an endpoint would do with the

---

From: "Zhangxian (Xian)" <[email-masked]>
Date: Fri, 8 Apr 2016 13:55:54 +0000

Hi, All, 

     It seems to me that exposing whether the SRLG list for LSP is complete or not may make some sense. 

    The last time I checked this draft, I remember there are some extensions to support indicating per node if SRLG is complete or not. But as Matt has already explained that the authors agreed to remove it, i fully understand and agree the reason not doing so per node. But it would be good to solicit some more feedbacks on doing this per LSP.
 
Regards,
Xian

________________________________________
发件人: Teas [[email-masked]] 代表 Dieter Beller [[email-masked]]
发送时间: 2016年4月8日 2:04
收件人: EXT Shah, Himanshu; Matt Hartley (mhartley)
抄送: [email-masked]
主题: Re: [Teas] I-D Action: draft-ietf-teas-rsvp-te-srlg-collect-05.txt

Hi Matt,Himanshu, all,

Thanks,
Dieter

---

From: Gert Grammel <[email-masked]>
Date: Fri, 8 Apr 2016 16:55:14 +0000

I tend to agree with Matt. There is anyhow nothing the head end can do. I also don't see a compelling reason to add a flag to expose what the operator decided not to expose.

Gert

Sent from my Apple ][

> On 08 Apr 2016, at 10:56, Zhangxian (Xian) <[email-masked]> wrote:
> 
> Hi, All, 
>

---

From: Julien Meuric <[email-masked]>
Date: Thu, 21 Apr 2016 11:35:27 +0200

Hi Himanshu, hi all,

I am glad to see the enthusiasm on this I-D and really eager to see 
widespread products implementing it.

In my humble opinion, the discussion in progress has missed one point: 
SRLGs aim to _model_ some lower layer resource dependency, but it can 
never perfectly describe an operational environment. In other words, 
full SRLG diversity cannot guarantee 100% physical diversity. I could 
even add that, SRLG ID space being network-local, there are case (e.g., 
carrier's carrier) where it would be misleading to summarize diversity 
as the comparison of 2 lists of IDs.

To summarize my point, I feel that a completion flag would be easily 
turned into:
- a "wild guess" index: how to draw the line between one missing short 
hop in a very verbose SRLG description and a full list from a network 
based on a very rough SRLG model?
- a "trust/bluff" flag: network X may flag as full whatever it is aware 
of, while Y may always flag a loose to avoid any 
commitment/responsibility on the information it sends;
- an information ignored by many implementation because SRLG policies 
vary very much between operators.
As a result, I believe it would be pointless to define it.

Thanks,

Julien

---

From: "Zafar Ali (zali)" <[email-masked]>
Date: Thu, 21 Apr 2016 12:20:35 +0000

Hi- 

I second what Julien said. I fear most SP will assume a policy to set this
³partial recording" flag (in fear of not providing a true diversity - like
Julien mentioned). Furthermore, in the control plane we cannot do much
with this flag.  

Thanks

Regards Š Zafar

On 4/21/16, 5:35 AM, "Teas on behalf of Julien Meuric"
<[email-masked] on behalf of [email-masked]> wrote:

>>operator, even when he
>>diverse and which may not be

---

From: "BRUNGARD, DEBORAH A" <[email-masked]>
Date: Tue, 26 Apr 2016 20:31:14 +0000

Agree with Julien-
Julien - your opinion is not humble:-) It reflects physical reality.
Deborah
(operator hat on)

-----Original Message-----
From: Teas [mailto:[email-masked]] On Behalf Of Julien Meuric
Sent: Thursday, April 21, 2016 5:35 AM
To: [email-masked]
Subject: Re: [Teas] I-D Action: draft-ietf-teas-rsvp-te-srlg-collect-05.txt

Hi Himanshu, hi all,

Thanks,

Julien

---

From: "Matt Hartley (mhartley)" <[email-masked]>
Date: Wed, 27 Apr 2016 18:04:39 +0000

So, it seems we have a split verdict :)

I'd like to move the draft forward, and I think we have a couple of options at this point:

1. Don't add any indication of SRLG completeness to the signaling process for now. This can be added as a subsequent enhancement in a new draft if there is perceived to be a need for it in future.

2. Add SRLG-completeness indication to the signaling, but do so in such a way that it's optional (i.e. so that the draft can be implemented and deployed without it).

Given that the operators who have spoken up don't see a need for it, I don't think it would be a good idea to make this mandatory for implementors.

Thoughts?

Cheers

Matt

> never perfectly describe an operational environment. In other words, full
> SRLG diversity cannot guarantee 100% physical diversity. I could even add
> that, SRLG ID space being network-local, there are case (e.g., carrier's
> carrier) where it would be misleading to summarize diversity as the
> comparison of 2 lists of IDs.
> 
> - a "wild guess" index: how to draw the line between one missing short hop
> in a very verbose SRLG description and a full list from a network based on
> a very rough SRLG model?
> of, while Y may always flag a loose to avoid any commitment/responsibility
> on the information it sends;
> - an information ignored by many implementation because SRLG policies vary
> very much between operators.
> > operator, even when he may have set SRLG-non-disclose policy for a given
> node within one area or other area across ABR.
> >
> > what path a specific LSP would take as it is based on TE requirements of
> the LSP and current resource availability state of the network.
> >
> be aware of what information will and won't traverse the PE/CE boundary as
> there would be some sort of contract/agreement on that.
> >

---

From: "Shah, Himanshu" <[email-masked]>
Date: Wed, 27 Apr 2016 16:07:31 -0400

Sorry - a little behind on this thread..

Basically, what you are saying is the receiver should not trust this flag
and for that matter even the values one receives as it may not be meaningful.

So then why are we doing this draft?

Thanks,
Himanshu

-----Original Message-----
From: Teas [mailto:[email-masked]] On Behalf Of Julien Meuric
Sent: Thursday, April 21, 2016 2:35 AM
To: [email-masked]
Subject: Re: [Teas] I-D Action: draft-ietf-teas-rsvp-te-srlg-collect-05.txt

Hi Himanshu, hi all,

I am glad to see the enthusiasm on this I-D and really eager to see widespread products implementing it.

In my humble opinion, the discussion in progress has missed one point: 
SRLGs aim to _model_ some lower layer resource dependency, but it can never perfectly describe an operational environment. In other words, full SRLG diversity cannot guarantee 100% physical diversity. I could even add that, SRLG ID space being network-local, there are case (e.g., carrier's carrier) where it would be misleading to summarize diversity as the comparison of 2 lists of IDs.

To summarize my point, I feel that a completion flag would be easily turned into:
- a "wild guess" index: how to draw the line between one missing short hop in a very verbose SRLG description and a full list from a network based on a very rough SRLG model?
- a "trust/bluff" flag: network X may flag as full whatever it is aware of, while Y may always flag a loose to avoid any commitment/responsibility on the information it sends;
- an information ignored by many implementation because SRLG policies vary very much between operators.
As a result, I believe it would be pointless to define it.

Thanks,

Julien

---

From: "Matt Hartley (mhartley)" <[email-masked]>
Date: Wed, 27 Apr 2016 20:50:25 +0000

Himanshu,

> and for that matter even the values one receives as it may not be

No, that's not what anyone's saying.

The values received can be trusted, and are therefore useful. The point is that in many cases the nodes supplying them may not be able to guarantee their completeness, and therefore operators would always set the 'incomplete' flag out of an abundance of caution. This is more about humans playing it safe. "incomplete" is not the same as "not meaningful" or "useless".

Cheers

Matt

---

From: "Shah, Himanshu" <[email-masked]>
Date: Wed, 27 Apr 2016 17:41:31 -0400

Hi Matt-

Can you expand on what "guarantee their completeness"?
Are all values configured on the affected links are returned or not?
Are only subset returned?
The values are returned but semantics of those values are not known and hence it is incomplete?

And when we think through those answers, we can understand the scope of the flag as well.
In most simplistic view, flag only says - I had 10 values, I am not going to reveal what those 
10 values are, Or I will only give you any random 5 values, and to be a nice citizenry, I will tell you that list is incomplete (for example). 

Thanks,
Himanshu

-----Original Message-----
From: Matt Hartley (mhartley) [mailto:[email-masked]] 
Sent: Wednesday, April 27, 2016 1:50 PM
To: Shah, Himanshu; Julien Meuric; [email-masked]
Cc: Matt Hartley (mhartley)
Subject: RE: [Teas] I-D Action: draft-ietf-teas-rsvp-te-srlg-collect-05.txt

Himanshu,

> Basically, what you are saying is the receiver should not trust this 
> flag and for that matter even the values one receives as it may not be 
> meaningful.

Cheers

Matt

> even add that, SRLG ID space being network-local, there are case 
> (e.g., carrier's
> - a "trust/bluff" flag: network X may flag as full whatever it is 
> aware of, while Y may always flag a loose to avoid any 
> > I still believe there is utility in obtaining this information for 
> > the operator, even when he may have set SRLG-non-disclose policy for 
> > a given
> > So it would be important which 1:1 linear protected LSPs are 
> > strictly diverse and which may not be strictly diverse based on the 
> > fact that
> > already
> be aware of what information will and won't traverse the PE/CE 
> > see
> much benefit in the additional complexity of adding that information 
> to the signaled objects.
> >
> > Cheers
> >
> > Matt
> >
> >> Thanks,
> >> Himanshu
> >>
> >>>> no SRLG based on the local policy (hope I understood this correctly).
> >>> Yes.
> >>>
> >>>> When that is

---

From: "Matt Hartley (mhartley)" <[email-masked]>
Date: Thu, 28 Apr 2016 03:32:36 +0000

Himanshu,

> Can you expand on what "guarantee their completeness"?

Julien explained this in his mail, e.g. the carrier over carrier case.

> Are only subset returned?

Depends on policy, as described in the draft.

> The values are returned but semantics of those values are not known and

It's not about semantics; the definition of a SRLG ID doesn't change.

> 10 values are, Or I will only give you any random 5 values, and to be a
> nice citizenry, I will tell you that list is incomplete (for example).

The point, as Julien explained, is that if the flag exists then operators will end up setting it all the time, just in case. And that means it isn't of any practical use.

Cheers

Matt

> The values received can be trusted, and are therefore useful. The point is
> that in many cases the nodes supplying them may not be able to guarantee
> their completeness, and therefore operators would always set the
> 'incomplete' flag out of an abundance of caution. This is more about
> humans playing it safe. "incomplete" is not the same as "not meaningful"
> or "useless".
> 
> Cheers
> 
> Matt
>

---

From: Vishnu Pavan Beeram <[email-masked]>
Date: Thu, 28 Apr 2016 16:22:38 -0400

Folks, Hi!

I think we have spent sufficient cycles on this topic and it is time to
move on. Based on the discussion so far on this thread, I would like to
conclude that no compelling reason (/use-case) has been put forth to
warrant the introduction of a new flag in the draft.

I’d be initiating a second WG LC for the draft shortly.

Regards,
-Pavan

On Wed, Apr 27, 2016 at 11:32 PM, Matt Hartley (mhartley) <
[email-masked]> wrote:

> The point, as Julien explained, is that if the flag exists then operators
> will end up setting it all the time, just in case. And that means it isn't
> of any practical use.
>
> Cheers
>
> Matt
>
> >
> > Thanks,
> > Himanshu
> >
> >
> > > >>>>>       Filename        :