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

[Vishnu Pavan Beeram <[e-mail]>]

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) <
[e-mail]> wrote:

> 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
>
> _______________________________________________
> Teas mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/teas
>