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

["Matt Hartley (mhartley)" <[e-mail]>]

Himanshu,

> Hi Matt-
> 
> Can you expand on what "guarantee their completeness"?

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

> Are all values configured on the affected links are returned or not?
> 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
> hence it is incomplete?

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

> 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).

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
> 
> 
> -----Original Message-----
> From: Matt Hartley (mhartley) [mailto:[e-mail]]
> Sent: Wednesday, April 27, 2016 1:50 PM
> To: Shah, Himanshu; Julien Meuric; [e-mail]
> Cc: Matt Hartley (mhartley)
> Subject: RE: [Teas] I-D Action: draft-ietf-teas-rsvp-te-srlg-collect-
> 05.txt
> 
> Himanshu,
> 
> > 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.
> 
> 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
> 
> > So then why are we doing this draft?
> >
> > Thanks,
> > Himanshu
> >
> >
> > -----Original Message-----
> > From: Teas [mailto:[e-mail]] On Behalf Of Julien Meuric
> > Sent: Thursday, April 21, 2016 2:35 AM
> > To: [e-mail]
> > 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
> >
> >
> > Apr. 07, 2016 - Shah, Himanshu:
> > > 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