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

[Gert Grammel <[e-mail]>]

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) <[e-mail]> wrote:
> 
> 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 [[e-mail]] 代表 Dieter Beller [[e-mail]]
> 发送时间: 2016年4月8日 2:04
> 收件人: EXT Shah, Himanshu; Matt Hartley (mhartley)
> 抄送: [e-mail]
> 主题: 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:
>> 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:[e-mail]]
>> Sent: Thursday, April 07, 2016 11:24 AM
>> To: Shah, Himanshu
>> Cc: [e-mail]; 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.
>> 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
>> 
>>> Thanks,
>>> Himanshu
>>> 
>>> -----Original Message-----
>>> From: Matt Hartley (mhartley) [mailto:[e-mail]]
>>> Sent: Tuesday, April 05, 2016 1:39 PM
>>> To: Shah, Himanshu
>>> Cc: [e-mail]; 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?
>>> 
>>> 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
>>>> 
>>>> 
>>>> -----Original Message-----
>>>> From: Matt Hartley (mhartley) [mailto:[e-mail]]
>>>> Sent: Monday, April 04, 2016 2:07 PM
>>>> To: Shah, Himanshu
>>>> Cc: [e-mail]; Matt Hartley (mhartley)
>>>> Subject: RE: [Teas] I-D Action:
>>>> draft-ietf-teas-rsvp-te-srlg-collect-
>>>> 05.txt
>>>> 
>>>> 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:[e-mail]] On Behalf Of Matt
>>>>> Hartley
>>>>> (mhartley)
>>>>> Sent: Monday, April 04, 2016 1:30 PM
>>>>> To: [e-mail]; [e-mail]
>>>>> Cc: Matt Hartley (mhartley); [e-mail]
>>>>> 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
>>>>> 
>>>>>> 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-co
>>>>>> ll
>>>>>> ec
>>>>>> t/
>>>>>> 
>>>>>> There's also a htmlized version available at:
>>>>>> https://tools.ietf.org/html/draft-ietf-teas-rsvp-te-srlg-collect
>>>>>> -0
>>>>>> 5
>>>>>> 
>>>>>> A diff from the previous version is available at:
>>>>>> 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.
>>>>>> 
>>>>>> Internet-Drafts are also available by anonymous FTP at:
>>>>>> ftp://ftp.ietf.org/internet-drafts/
>>>>>> 
>>>>>> _______________________________________________
>>>>>> Teas mailing list
>>>>>> [e-mail]
>>>>>> https://www.ietf.org/mailman/listinfo/teas
>>>>> _______________________________________________
>>>>> Teas mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/teas
>> 
>> _______________________________________________
>> Teas mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/teas
> 
> _______________________________________________
> Teas mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/teas
> _______________________________________________
> Teas mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/teas