Hi Reshad, I've got them. I will re-send several from the RFC Editor shortly.
Regards, Greg On Sat, Dec 19, 2020 at 7:08 AM Reshad Rahman <res...@yahoo.com> wrote: > Hi, > > We have had discussions recently with the RFC Editor wrt changes needed in > draft-ietf-bfd-yang. Unfortunately I don't have access to those emails > anymore. I don't know whether we can access the latest text in the draft. > > Regards, > Reshad. > > On 2020-12-19, 8:04 AM, "Rtg-bfd on behalf of tom petch" < > rtg-bfd-boun...@ietf.org on behalf of ie...@btconnect.com> wrote: > > From: Rtg-bfd <rtg-bfd-boun...@ietf.org> on behalf of tom petch < > ie...@btconnect.com> > Sent: 06 November 2020 12:58 > > From: Reshad Rahman (rrahman) <rrah...@cisco.com> > Sent: 21 August 2020 12:31 > > On 2020-08-21, 5:57 AM, "tom petch" <ie...@btconnect.com> wrote: > > From: Reshad Rahman (rrahman) <rrah...@cisco.com> > Sent: 20 August 2020 18:42 > > I had noticed the lsps vs lsps-state, mentioned it at last BFD WG > meeting and have been in touch with the teas-yang authors. > > I hadn't noticed that mpls:enabled had been removed. I'll have to > go through all MPLS-related items in the BFD yang. > > <tp> > mpls-base has been approved by the IESG and is wending its way through > the system and that is a Normative dependency for bfd-yang so the there > might be progress on bfd-yang. I had a look at the tools pages and MISSREF > but do not understand what it is telling me:-( > > <tp2> > > mpls-base is now RFC8960. As yet I do not see any consequential > changes in the I-D in the RFC Editor Q but I am not sure what I should be > looking for so I shall keep looking :-) > > Tom Petch > > > <tp> > Yes please; enabled is still there but in a different place; I > have not gone back to mpls-base-yang-03 to see if the semantics are the > same. > > Note my third rather indecisive comment that mpls-base-yang now > models mpls in a different way, splitting IP routes with some MPLS, from > MPLS only routes, with no IP, as described in mpls-base-yang-15; I have not > got my head around this and do not know how it fits with bfd but suspect > that it needs some thinking about. > <RR> I don't think it has an impact because BFD uses an IP-prefix as > MPLS-FEC. But I will take a look. > > I read the meeting minutes but your significant (for me) > contribution appears to have passed the minute taker by:-) > <RR> It was mentioned in the chairs slides though. > > Regards, > Reshad. > > Tom Petch > > > > Regards, > Reshad. > > On 2020-08-20, 12:33 PM, "t petch" <ie...@btconnect.com> wrote: > > Yes bfd-yang. Sometimes I would like to be wrong. > > When I look at this I-D, I see that it references > > /rt:routing/mpls:mpls/mpls:interface/mpls:config/mpls:enabled > In 2018, the MPLS WG removed that /config from the > mpls-base-yang so > this would seem to be no longer valid. What needs changing to > rectify > this I have not explored. > > The I-D has > augment "/te:te/te:lsps-state/te:lsp" > which I no longer see in draft-ietf-teas-yang-te - the -state > has gone. > Again, I have not explored the ramifications of this. > > MPLS WG has a new base-yang out this week which differentiates > between > an IP route with a MPLS next hop and a MPLS route with no IP, > the latter > forming a new, mpls Address Family. I would think that the > latter is > not catered for by BFD but it would be nice to be wrong > > Tom Petch > > > > > > > >
