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

["Zafar Ali (zali)" <[e-mail]>]

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" <[e-mail]
on behalf of [e-mail]> 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 
>
>
>-----Original Message-----
>From: Teas <[e-mail]> on behalf of "Shah, Himanshu"
><[e-mail]>
>Date: Thursday, April 7, 2016 at 11:37
>To: "Matt Hartley (mhartley)" <[e-mail]>
>Cc: "[e-mail]" <[e-mail]>
>Subject: Re: [Teas] I-D Action:
>draft-ietf-teas-rsvp-te-srlg-collect-05.txt
>
>>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