Ladislav Lhotka | 27 Feb 12:49 2015
Picon

Re: [Rtg-yang-coord] rtg-cfg hierachy (Indentation in hierarchy corrected)

Dean Bogdanovic <deanb <at> juniper.net> writes:

> On Feb 23, 2015, at 8:05 AM, Ladislav Lhotka <lhotka <at> nic.cz> wrote:
>> 
>>> 
>>> This would imply that RIBs are within a routing-instance and that
>> 
>> It seems (Junos experts, please confirm) that in Junos user-defined
>> routing tables can be specified both globally and per routing-instance:
>> 
>> http://www.juniper.net/documentation/en_US/junos14.2/topics/reference/configuration-statement/export-rib-edit-routing-options.html
>
> Lada,
>
> Not sure what are you are getting at. In Junos you create rib-groups

I am trying to figure out whether it is absolutely safe to assume that
every RIB can be confined to a single routing instance - Acee proposed
to make "ribs" a child of "routing-instance" whereas now it is global (a
child of "routing").

Lada

> and within rib-groups multiple RIBs can be specified. A RIB group is a
> way to have a routing protocol, place information in multiple route
> tables. And then you are exporting from rib-group RIBs to RIBs within
> routing-instances. Or vice versa, importing from RIBs in
> routing-instances into rib-groups.

>
(Continue reading)

Alia Atlas | 23 Feb 21:15 2015
Picon

RTGWG chairs

Hi RTGWG,

From Weds evening of IETF-92, Alvaro will be serving as Routing AD so it isn't appropriate for him to continue to chair a WG in the Routing Area.  Thus, Alvaro is stepping down as co-chair of RTGWG.  I really appreciate the hard work that Alvaro has done as RTGWG co-chair.

I have consulted with Alvaro, Deborah, Adrian, and Jeff, and have decided to appoint Chris Bowers to serve in this role.  Chris will be busy ramping up.  I expect the handover to be finished in Dallas.

Chris can be reached at cbowers <at> juniper.net.

Thanks,
Alia

_______________________________________________
rtgwg mailing list
rtgwg <at> ietf.org
https://www.ietf.org/mailman/listinfo/rtgwg
Pushpasis Sarkar | 20 Feb 15:31 2015
Picon

FW: New Version Notification for draft-psarkar-rtgwg-multihomed-prefix-lfa-01.txt

Hi Everyone,

Just posted an updated version with few additions. Request you all to
please review it and provide your valuable feedback.

Thanks and Regards,
-Pushpasis

On 2/20/15, 7:59 PM, "internet-drafts <at> ietf.org" <internet-drafts <at> ietf.org>
wrote:

>
>A new version of I-D, draft-psarkar-rtgwg-multihomed-prefix-lfa-01.txt
>has been successfully submitted by Pushpasis Sarkar and posted to the
>IETF repository.
>
>Name:		draft-psarkar-rtgwg-multihomed-prefix-lfa
>Revision:	01
>Title:		LFA selection for Multi-Homed Prefixes
>Document date:	2015-02-20
>Group:		Individual Submission
>Pages:		10
>URL:            
>http://www.ietf.org/internet-drafts/draft-psarkar-rtgwg-multihomed-prefix-
>lfa-01.txt
>Status:         
>https://datatracker.ietf.org/doc/draft-psarkar-rtgwg-multihomed-prefix-lfa
>/
>Htmlized:       
>http://tools.ietf.org/html/draft-psarkar-rtgwg-multihomed-prefix-lfa-01
>Diff:           
>http://www.ietf.org/rfcdiff?url2=draft-psarkar-rtgwg-multihomed-prefix-lfa
>-01
>
>Abstract:
>   This document shares experience gained from implementing algorithms
>   to determine Loop-Free Alternates for multi-homed prefixes.  In
>   particular, this document provides explicit inequalities that can be
>   used to evaluate neighbors as a potential alternates for multi-homed
>   prefixes.  It also provides detailed criteria for evaluating
>   potential alternates for external prefixes advertised by OSPF ASBRs.
>
>
>                  
>        
>
>
>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.
>
>The IETF Secretariat
>
stephane.litkowski | 20 Feb 08:21 2015

LFA manageability : per AF config => feedback required

Hi Folks,

 

As you know, LFA manageability draft is in final phasis …

The current document states per AF granularity activation as a SHOULD.

5.1.  LFA enabling/disabling scope

 

 

   The granularity of LFA activation should be controlled (as alternate

   nexthop consume memory in forwarding plane).

 

   An implementation of LFA SHOULD allow its activation with the

   following criteria:

 

   o  Per address-family : ipv4 unicast, ipv6 unicast, LDP IPv4 unicast,

      LDP IPv6 unicast ...

 

   o  Per routing context : VRF, virtual/logical router, global routing

      table, ...

 

 

In the framework of ISIS/OSPF yang modelization, we are challenging this statement, do we really need to force implementation to support this “per AF” granularity ?

 

Please provide as soon as possible your feedback on this and also provide clear drivers to support or not per AF activation of LFA.

 

 

Thanks for your help !

 

 

 

Stephane Litkowski
Network Architect
Orange/SCE/EQUANT/IBNF/ENDD/NDE

Orange Expert Future Networks

phone: +33 2 23 28 49 83
mobile: +33 6 37 86 97 52
stephane.litkowski <at> orange.com

 

 

_________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you.
_______________________________________________
rtgwg mailing list
rtgwg <at> ietf.org
https://www.ietf.org/mailman/listinfo/rtgwg
Thomas Morin | 18 Feb 12:36 2015

Re: rtg-cfg hierachy (PLEASE REPLY TO THIS ONE WITH THE CORRECT MAIL ALIASES)

Hi Acee, Lada,

It seems that my comment that you quote was more related to filters than 
to routing tables, and indeed, *filters* were moved from "router" to 
"global" in revision -03 that followed my review.

Additionally, Lada, you say that based on my comments "in rev. -03 the 
list of RIBs (then called "routing-table") was the moved out of the 
routing instance (then called "router") and became global.". But if I 
look at -03, "routing-table" is still a child of "router".  The change 
to make "routing-table" global was made in -05.

I guess you need to find out what was the motivation for the change in 
-05, a few months after my initial comments were address.

Best,

-Thomas

2015-02-13, Acee Lindem (acee):
>
> Hi Lada, Thomas,
>
> On 2/13/15, 5:10 AM, "Ladislav Lhotka" <lhotka <at> nic.cz> wrote:
>
>> Hi,
>>
>> "Acee Lindem (acee)" <acee <at> cisco.com> writes:
>>
>>> Hi Thomas,
>>>
>>> It is my understanding that the RIBs were moved out of the
>>> routing-instance in response to your comment that a RIB would need to be
>>> attached to multiple routing instances. I don¹t agree with this
>>> model. I
>>
>> Acee refers to this comment that Thomas made in his review of
>> draft-ietf-netmod-routing-cfg-02 on 2012-03-23:
>>
>> "Allowing multiple "routers" is a good starting point for using these
>> specs in the context of RFC4364 (MPLS/BGP IP VPNs). However, if I
>> understand correctly Yang syntax, the way the filters are defined would
>> not work in the context of RFC4364, where a BGP routing instance in the
>> master "router" exports selected routes in each of the routing table of
>> each VPN (VRF).  The VRF also export routes to the master instance."
>>
>> And indeed, in rev. -03 the list of RIBs (then called "routing-table")
>> was the moved out of the routing instance (then called "router") and
>> became global.
>
> Then do you agree to move the RIBs back into the routing-instance? Both
> the BGP YANG drafts model L3VPN definitions under the corresponding
> address family in BGP.
>
> http://www.ietf.org/id/draft-shaikh-idr-bgp-model-00.txt
> http://www.ietf.org/id/draft-zhdankin-idr-bgp-cfg-00.txt
>
> Thanks,
> Acee
>
>
>
>>
>> Lada
>>
>>> believe that a routing instance implies a VRF, virtual router or
>>> something
>>> in between and that a RIB should be associated with one and only one
>>> routing instance. Additionally, I feel that RIBs are basically passive
>>> entities with respect to import/export of routes between RIBs in the
>>> same
>>> or other routing-instances. Rather, all import/export is under the
>>> control
>>> of a routing-protocol. For example, this would be handled by a BGP
>>> routing-protocol instance for L3VPNs.
>>>
>>> I¹d like to get the opinions of others on this fundamental aspect of the
>>> rtg-cfg model.
>>>
>>> Thanks,
>>> Acee
>>>
>>>
>>
>> --
>> Ladislav Lhotka, CZ.NIC Labs
>> PGP Key ID: E74E8C0C
>
>
>

_______________________________________________
rtgwg mailing list
rtgwg <at> ietf.org
https://www.ietf.org/mailman/listinfo/rtgwg
t.petch | 17 Feb 13:32 2015

Fw: Interim meetings - changing the way we work

Adrian, Alia

Looking for the outcome of an Interim meeting on the IETF website, I
became aware of how rarely the proceedings are fully reported (as I
posted to the main IETF list recently).

Of the meetings in 2014 that produced no Minutes, three are in the
Routing
Area,
2014-12-18 teas
2014-12-15 bier
2014-10-21 nvo3

These are not lists I normally follow but I did look at the Mailing List
Archives and, for all three, there is mention of 'Rough' or 'Draft'
minutes, in one case even adding

'I will post them to the meeting materials, by end of this week'

Thoughts?

Tom Petch

----- Original Message -----
From: "t.p." <daedulus <at> btconnect.com>
To: "ietf" <ietf <at> ietf.org>
Sent: Sunday, February 15, 2015 1:57 PM
Subject: Interim meetings - changing the way we work

> There has been a marked increase in the number of  interim meetings.
> Using
> http://www.ietf.org/meeting/interim/proceedings.html
> as a guide, there were
> 18 in 2011
> 35 in 2012
> 45 in 2013
> 84 in 2014
> 13 in January 2015 alone.
>
> With them comes a change in the way of working, perhaps rendering some
> of our practices historic.
>
> Of the 84 meetings listed for 2014, 21 left no other trace on the IETF
> web site, no Agenda, no Minutes, no Proceedings.  Perhaps the WG
> provided no materials, perhaps they did not happen; sometimes a
> cancellation notice is apparent in the WG List Archives, other times
> not.
>
> Of the 63 that have left a trace, 6 produced no Minutes but did
produce
> slides or recordings and so presumably happened.
>
> Of the 57 that produced Minutes, 18 produced no Agenda while in 13
> cases, the Minutes contained no list of Attendees (goodbye Blue
> Sheets?).
>
> Only 26 meetings left a complete record, of Agenda, Minutes and
> Attendees.
>
> The meetings encompassed 30 Working Groups, of which 16 met once, 14
> more than once, with one WG meeting 8 times.
>
> What is more subjective is that, with Virtual Interims, increasingly
the
> only kind, there is a tendency for the WG Mailing List to no longer
> provide a record of discussions, choices, consensus.  For example,
they
> may make greater use of github so that the minutes record a discussion
> of options 1, 2 and 3 for Issue 29 with no indication of what the
issue
> or options are; a while later, they may record an update to option 3
so
> it would now seem impossible to know what was discussed at the earlier
> meeting.
>
> Even with the better minutes, they never give the same sense as posts
to
> a mailing list of who was or was not in favour and how strong their
view
> was.
>
> Of course, we still have WG Last Calls on the list but if at a future
> date, an AD or GenArt reviewer wants to look back and see what options
> were discussed and  how rough the consensus was, well, it may be
> impossible.
>
> A post in another thread recently said
>
> > I do think that the increased significance of meetings
> > in IETF participation (and here, I'm not talking about
> > things like nomcom but about significance to our technical
> > work) is a problem, both because it tends to marginalize
> > people who can't come to meetings and because it slows
> > work down.
>
> Well, I disagree about slowing the work down but certainly agree with
> the marginalisation, that WGs holding multiple Interims may tend to
> develop an in-crowd of those that can participate with the world at
> large only seeing the end result without knowing how it was arrived at
> by whom.
>
> Tom Petch
>
Jeff Tantsura | 16 Feb 07:28 2015
Picon

RTGWG timeslots for Dallas

Hi RTGWG,

IETF92 is approaching, please request a timeslot if you are planning to
present, usual disclaimer applies - no draft/no time.

Thanks!

Cheers,
Jeff
Chris Bowers | 14 Feb 01:36 2015
Picon

FW: New Version Notification for draft-bowers-rtgwg-mrt-applicability-to-8021qca-00.txt

I'd like to bring the following draft to the attention of the RTGWG.  It discusses the applicability of the
MRT algorithm to IEEE 802.1Qca Path Control and Reservation for bridged networks.

Chris

-----Original Message-----
From: internet-drafts <at> ietf.org [mailto:internet-drafts <at> ietf.org] 
Sent: Friday, February 13, 2015 6:31 PM
To: Chris Bowers; Chris Bowers; Janos Farkas; Janos Farkas
Subject: New Version Notification for draft-bowers-rtgwg-mrt-applicability-to-8021qca-00.txt

A new version of I-D, draft-bowers-rtgwg-mrt-applicability-to-8021qca-00.txt
has been successfully submitted by Chris Bowers and posted to the IETF repository.

Name:		draft-bowers-rtgwg-mrt-applicability-to-8021qca
Revision:	00
Title:		Applicability of Maximally Redundant Trees to IEEE 802.1Qca Path Control and Reservation
Document date:	2015-02-13
Group:		Individual Submission
Pages:		7
URL:            http://www.ietf.org/internet-drafts/draft-bowers-rtgwg-mrt-applicability-to-8021qca-00.txt
Status:         https://datatracker.ietf.org/doc/draft-bowers-rtgwg-mrt-applicability-to-8021qca/
Htmlized:       http://tools.ietf.org/html/draft-bowers-rtgwg-mrt-applicability-to-8021qca-00

Abstract:
   IEEE 802.1Qca Path Control and Reservation (PCR) [IEEE8021Qca] uses
   the algorithm specified in [I-D.ietf-rtgwg-mrt-frr-algorithm] to
   compute Maximally Redundant Trees (MRTs) to be used for the
   protection of data traffic in bridged networks.  This document
   discusses the applicability of the MRT algorithm to 802.1Qca.

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.

The IETF Secretariat
Acee Lindem (acee | 13 Feb 19:31 2015
Picon

Re: rtg-cfg hierachy (PLEASE REPLY TO THIS ONE WITH THE CORRECT MAIL ALIASES)

Hi Lada, Thomas, 

On 2/13/15, 5:10 AM, "Ladislav Lhotka" <lhotka <at> nic.cz> wrote:

>Hi,
>
>"Acee Lindem (acee)" <acee <at> cisco.com> writes:
>
>>Hi Thomas, 
>>
>>It is my understanding that the RIBs were moved out of the
>>routing-instance in response to your comment that a RIB would need to be
>>attached to multiple routing instances. I don¹t agree with this
>>model. I
>
>Acee refers to this comment that Thomas made in his review of
>draft-ietf-netmod-routing-cfg-02 on 2012-03-23:
>
>"Allowing multiple "routers" is a good starting point for using these
>specs in the context of RFC4364 (MPLS/BGP IP VPNs). However, if I
>understand correctly Yang syntax, the way the filters are defined would
>not work in the context of RFC4364, where a BGP routing instance in the
>master "router" exports selected routes in each of the routing table of
>each VPN (VRF).  The VRF also export routes to the master instance."
>
>And indeed, in rev. -03 the list of RIBs (then called "routing-table")
>was the moved out of the routing instance (then called "router") and
>became global.

Then do you agree to move the RIBs back into the routing-instance? Both
the BGP YANG drafts model L3VPN definitions under the corresponding
address family in BGP.

http://www.ietf.org/id/draft-shaikh-idr-bgp-model-00.txt

http://www.ietf.org/id/draft-zhdankin-idr-bgp-cfg-00.txt


Thanks,
Acee 



>
>Lada
>
>>believe that a routing instance implies a VRF, virtual router or
>>something
>>in between and that a RIB should be associated with one and only one
>>routing instance. Additionally, I feel that RIBs are basically passive
>>entities with respect to import/export of routes between RIBs in the
>>same
>>or other routing-instances. Rather, all import/export is under the
>>control
>>of a routing-protocol. For example, this would be handled by a BGP
>>routing-protocol instance for L3VPNs.
>>
>>I¹d like to get the opinions of others on this fundamental aspect of the
>>rtg-cfg model. 
>>
>>Thanks,
>>Acee 
>>
>>
>
>-- 
>Ladislav Lhotka, CZ.NIC Labs
>PGP Key ID: E74E8C0C



_______________________________________________
rtgwg mailing list
rtgwg <at> ietf.org
https://www.ietf.org/mailman/listinfo/rtgwg
Acee Lindem (acee | 13 Feb 00:09 2015
Picon

Re: [Rtg-yang-coord] issue :R03: assignment of interfaces to routing instances

I believe the fact that we are having trouble resolving this is that the
model is wrong. I would propose the following:

   1. Remove the interface list completely from rtf-cfg configuration.
   2. Augment the RFC 7223 to include a reference to a routing-instance.
An interface should be part of one and only one routing-instance.
   3. Provide a list of interfaces in the operational state in the rtg-cfg
model. 

One reason I'm proposing this change is that I believe a routing-instance
implies an IPv4/IPv6 address space and the interfaces list MUST NOT be
disjoint from the assigned addresses (refer to RFC 7277). If you want to
have a list of interfaces in the routing-instance, you should deprecate
RFC 7277 or, at least, say that it only applies to the default instance.

In all fairness, Lada disagrees with me on this point and wants the
flexibility of associating an interface with multiple routing-instances.
Additionally, he feels that the list inside the routing-instance will
facilitate better interface selection checking. I don¹t see the latter as
an issue as the same checking could be applied when an attempt is made to
augment the RFC 7223 interface.

Thanks,
Acee 

On 1/14/15, 12:46 PM, "Juergen Schoenwaelder"
<j.schoenwaelder <at> jacobs-university.de> wrote:

>On Wed, Jan 14, 2015 at 04:43:29PM +0000, Xufeng Liu wrote:
>> Hi Andy,
>> 
>> The concatenated string format is actually what we plan to do. However,
>>to me, it is more like a hack than an engineered solution. The model
>>fails to capture such a relationship properly.
>>
>
>If your interface names are no unique, I would assume that you will
>face other issues as well. For example, one may use an interface name
>to disambiguate link-local addresses. I am not sure how that works if
>your interface name is not unique.
>
>/js
>
>-- 
>Juergen Schoenwaelder           Jacobs University Bremen gGmbH
>Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
>Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>
Acee Lindem (acee | 13 Feb 00:05 2015
Picon

rtg-cfg draft hierarchy (Reply to this one)

Hi Thomas, 

It is my understanding that the RIBs were moved out of the
routing-instance in response to your comment that a RIB would need to be
attached to multiple routing instances. I don¹t agree with this model. I
believe that a routing instance implies a VRF, virtual router or something
in between and that a RIB should be associated with one and only one
routing instance. Additionally, I feel that RIBs are basically passive
entities with respect to import/export of routes between RIBs in the same
or other routing-instances. Rather, all import/export is under the control
of a routing-protocol. For example, this would be handled by a BGP
routing-protocol instance for L3VPNs.

I¹d like to get the opinions of others on this fundamental aspect of the
rtg-cfg model. 

Thanks,
Acee

_______________________________________________
rtgwg mailing list
rtgwg <at> ietf.org
https://www.ietf.org/mailman/listinfo/rtgwg

Gmane