IETF Secretariat | 25 Nov 23:47 2014
Picon

IPR Disclosure: Juniper's Statement of IPR related to draft-ietf-rtgwg-lfa-manageability-04


Dear Martin Horneffer, Stephane Litkowski, Bruno Decraene, Clarence Filsfils, Kamran Raza, psarkar <at> juniper.net:

 An IPR disclosure that pertains to your Internet-Draft entitled "Operational
management of Loop Free Alternates" (draft-ietf-rtgwg-lfa-manageability) was
submitted to the IETF Secretariat on 2014-11-24 and has been posted on the "IETF
Page of Intellectual Property Rights Disclosures"
(https://datatracker.ietf.org/ipr/2490/). The title of the IPR disclosure is
"Juniper's Statement of IPR related to draft-ietf-rtgwg-lfa-
manageability-04."");

The IETF Secretariat
Ladislav Lhotka | 25 Nov 14:03 2014
Picon

ietf-routing module issues

Hi,

below is a list of open issues regarding YANG modules contained in
draft-ietf-netmod-routing-cfg-16 that I think need further
discussion. I will start a new thread for each in the mailing list
rtg-yang-coord <at> ietf.org (no cross-posting). Therefore, I'd like to ask
folks in NETMOD and Routing Area WGs who are interested in these
discussions to subscribe to that list.

Thanks, Lada

***** :R01: route filters
***** :R02: complex next-hops
***** :R03: assignment of interfaces to routing instances
***** :R04: configuration and state data for IPv6 RA
***** :R05: numeric IDs of state data entries

--

-- 
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C
Alvaro Retana (aretana | 21 Nov 19:58 2014
Picon

Moving Forward with MRT (WAS: Re: [mpls] maturity of the MRT technology)

On 11/21/14, 6:49 AM, "Stewart Bryant (stbryant)" <stbryant <at> cisco.com> wrote:

[Stewart: Not directing this e-mail specifically at you…but at the WG.]

[Took off the draft-atlas-mpls-ldp-mrt alias since this is not a discussion specific to that draft.]

[Also took off the mpls alias as I intend to focus the discussion on the rtgwg process/consensus.  Left mpls-chairs as an FYI..we can later circle back to the mpls list.]

. . .
At the end of the day the utility of MRT depends on who is
interested in deploying it, and as far as I know, none of the 
domain wide IPFRR solutions have made it into production networks. 
If there are operators prepared to deploy MRT  in their production 
networks then obviously it is headed for the standards track. 
If it is destined to join the  ranks of the many "possible" domain
wide solutions, then it is clearly still at the informational/
experimental stage of its life.

It is true that MRT has been discussed widely in the WG (and offline)..and that no technical issues exist.

Just as a reminder, the rtgwg charter (in the description of the work related to FRR) reads: "All work in this area should be specifically evaluated by the WG in terms of practicality and applicability to deployed networks.”

Note that this statement doesn’t mean that we need deployments, or even people saying that they want/intend to deploy the technology.  It means that the WG should think of whether a proposal is applicable to deployed networks.  I would like to hear comments specific to this statement.

Thanks!

Alvaro.
_______________________________________________
rtgwg mailing list
rtgwg <at> ietf.org
https://www.ietf.org/mailman/listinfo/rtgwg
Alvaro Retana (aretana | 20 Nov 23:07 2014
Picon

rtgwg Draft Minutes Posted for IETF 91



Thanks to Acee for being our scribe.

Please send any comments/corrections before Dec/5.

Alvaro.
_______________________________________________
rtgwg mailing list
rtgwg <at> ietf.org
https://www.ietf.org/mailman/listinfo/rtgwg
Loa Andersson | 19 Nov 01:08 2014
Picon

maturity of the MRT technology

Working Groups,

We have don an MPLS-RT of draft-atlas-mpls-ldp-mrt, the reviews has been
posted to the mpls wg mailing list.

In his MPLS-RT review Stewart Bryant says:

"I have concerns about whether or not MRT technology has the  maturity
  expected in the standards track. However that decision needs to be
  taken in RTGWG and MPLS needs to follow their and lead in determining
  the fate and track of this draft. This draft should not be published
  ahead of the drafts that define the technology that it is supporting."

He also says that he see no reason not to go ahead and start the poll to
see if we have consensus to adopt the document as an mpls wg document.

The question Stewart ask is valid, and we'd like input from the rtgwg
and rtgwg chairs (copied on this mail). We will also copy both the
poll for adoption and the wglc to the rtgwg mailing list.

/Loa
mpls wg co-chair
--

-- 

Loa Andersson                        email: loa <at> mail01.huawei.com
Senior MPLS Expert                          loa <at> pi.nu
Huawei Technologies (consultant)     phone: +46 739 81 21 64
Acee Lindem (acee | 18 Nov 22:24 2014
Picon

Re: [netmod] High Level Comments on draft-ietf-netmod-rtg-cfg-16.txt

First, let me explain why I requested that the route-filters be removed
from the model. What I don't like about the route-filters is that they
are merely place-holders placed at a point-of-attachment which I don't
necessarily agree with.  Although we may end up with something similar,
these definitions should be in a more complete routing
policy model. Additionally, I believe it is obvious that there will
be both generic policy and protocol specific policy (e.g., BGP). If
these route-filters are to be included, there should be more guidance
as to precisely how they are to be used. Given their point-of-attachment,
they should clearly only be used for generic routing policy. Note that
for the two routing protocol instances (static and connected) defined
in draft-ietf-netmod-rtg-cfg, the import filters aren't even applicable.
This fact alone would suggest that this may not be the right
point-of-attachment for such routing policy. However, if I'm in the
minority, they can be retained for TBD augmentation.

As for the interface list in the routing-instance, I think it is
obvious that one should not define the address space for interface
disjointly from the IPv4/IPv6 interface addresses. That is why I
would recommend augmenting the RFC 7273 objects with a reference
to the routing instance rather having a disjoint interface
list in routing-instance as proposed.

Thanks,
Acee
P.S. netmod list bcc’ed. This discussion should take place on
rtg-yang-coord <at> ietf.org.





On 11/11/14, 4:58 PM, "Acee Lindem (acee)" <acee <at> cisco.com> wrote:

>I have two rather substantive comments on the draft we will be discussing
>in tomorrow¹s rtgwg meeting.
>
>   1. The draft includes stub definitions for import/export routing
>filters with the guidance that these should be augmented. I would like to
>see these removed from this draft as the whole area of routing policy
>should be worked on by a multi-vendor team similar to what is being done
>for the routing protocols. I don¹t think the direction should be set for
>routing policy based on these stub definitions.
>
>   2. The draft defines a list of interfaces that correspond to a
>routing-instance. The routing-instance binds the physical interface (RFC
>RFC 7273) to an address space. However, the IPv4/IPv6 interface addresses
>are specified via the YANG model in RFC 7277. I really don¹t like this
>disjoint specification. Rather, "/if:interfaces/if:interface"  in RFC 7273
>should be augmented in a reference to the routing instance. Additionally,
>the neighbor discovery definitions should augment the ipv6 container in
>RFC 7277). 
>
>I also have one question for the RTG WG - do we want this model to specify
>the precise forwarding behavior?
>
>  The draft states that ³backup next-hops are only used if no primary
>next-hops exist." This will relegate all implementations to the same IPFRR
>behavior. I don¹t think that this should be specified in this draft.
>
>Thanks,
>Acee 
>
>_______________________________________________
>netmod mailing list
>netmod <at> ietf.org
>https://www.ietf.org/mailman/listinfo/netmod


_______________________________________________
rtgwg mailing list
rtgwg <at> ietf.org
https://www.ietf.org/mailman/listinfo/rtgwg
Fred Baker (fred | 14 Nov 22:52 2014
Picon

Soliciting viewpoints and comments on source/destination routing

The chairs have asked me to solicit review and commentary on

https://datatracker.ietf.org/doc/draft-baker-rtgwg-src-dst-routing-use-cases
https://tools.ietf.org/html/draft-baker-rtgwg-src-dst-routing-use-cases
  "Requirements and Use Cases for Source/Destination Routing", Fred Baker,
  2014-10-21

There are at least two layers of discussion. One, as a working group, do we agree that there is a problem to
solve here? I obviously think there is, but I am one voice. Two, if the draft were to become a working group
draft, what would need to be added or changed?
_______________________________________________
rtgwg mailing list
rtgwg <at> ietf.org
https://www.ietf.org/mailman/listinfo/rtgwg
Acee Lindem (acee | 12 Nov 03:58 2014
Picon

High Level Comments on draft-ietf-netmod-rtg-cfg-16.txt

I have two rather substantive comments on the draft we will be discussing
in tomorrow¹s rtgwg meeting.

   1. The draft includes stub definitions for import/export routing
filters with the guidance that these should be augmented. I would like to
see these removed from this draft as the whole area of routing policy
should be worked on by a multi-vendor team similar to what is being done
for the routing protocols. I don¹t think the direction should be set for
routing policy based on these stub definitions.

   2. The draft defines a list of interfaces that correspond to a
routing-instance. The routing-instance binds the physical interface (RFC
RFC 7273) to an address space. However, the IPv4/IPv6 interface addresses
are specified via the YANG model in RFC 7277. I really don¹t like this
disjoint specification. Rather, "/if:interfaces/if:interface"  in RFC 7273
should be augmented in a reference to the routing instance. Additionally,
the neighbor discovery definitions should augment the ipv6 container in
RFC 7277). 

I also have one question for the RTG WG - do we want this model to specify
the precise forwarding behavior?

  The draft states that ³backup next-hops are only used if no primary
next-hops exist." This will relegate all implementations to the same IPFRR
behavior. I don¹t think that this should be specified in this draft.

Thanks,
Acee 
Jeff Tantsura | 10 Nov 21:54 2014
Picon

Working Group last call on draft-ietf-rtgwg-lfa-manageability - IPR

All,

In parallel to the WGLC for this draft, I want to formally ask the authors
(no additional contributors are listed in the latest version of the draft)
to please respond to this message indicating whether or not you are aware
of any relevant IPR.  The draft will not progress (pending the results of
the WGLC) until we have received a response from each author.

In addition, we wanted to take this opportunity to remind the entire WG
that the duty of disclosure is NOT limited to authors:

   (c) in order for the working group and the rest of the IETF to have
       the information needed to make an informed decision about the use
       of a particular technology, all those contributing to the working
       group's discussions must disclose the existence of any IPR the
       Contributor or other IETF participant believes Covers or may
       ultimately Cover the technology under discussion.  This applies
       to both Contributors and other participants, and applies whether
       they contribute in person, via email or by other means.  The
       requirement applies to all IPR of the participant, the
       participant's employer, sponsor, or others represented by the
       participants, that is reasonably and personally known to the
       participant.  No patent search is required.

RFC 3979 also points out disclosure must be "as soon as reasonably
possible":

   The IPR disclosure required pursuant to section 6.1.1 must be made as
   soon as reasonably possible after the Contribution is published in an
   Internet Draft unless the required disclosure is already on file.

Thank you!

Cheers,
Jeff
IJsbrand Wijnands | 10 Nov 20:23 2014
Picon

Re: New Version Notification for draft-yong-rtgwg-igp-multicast-arch-00.txt

Dear Lucy,

I have read through the draft, it reads very well, below are my comments:

1.1 Motivation

Ice: Creating a ‘multicast’ fabric can be done with PIM/mLDP/RSVP-TE as well, this is not a specific
benefit of adding tree building inside of the IGP. Note that the MVPN procedures (RFC6513) described
mechanisms similar to what is proposed in this draft, i.e. create a Mi-PMSI (default fabric) and S-PMSI
(specific trees). And RFC6514 describes how to use auto-provision those trees. It is not clear to me from
the draft (or use-case) that there is a reason to avoid BGP.

Ice: Longer convergence times of PIM compared to unicast are due to two factors, the delay of signalling
from RIB to PIM AND the amount of state (trees) that need to be updated in the PIM database. The first delay is
relatively small, say order of 100ms, the cost of updating a high number of PIM/mLDP trees is higher and
increases with the amount of state.

3.2.2. Parallel Local Link Selection

Quote from draft:
   “….Note that if multiple distribution trees are configured in a domain
   or on a router, better load balance among parallel links through the
   tie-breaking algorithm can be achieved. Otherwise, if there is only
   one tree is configured, then only one link in parallel links can be
   used for the corresponding distribution tree. However, calculating
   and maintaining many trees is resource consuming. Operators need to
   balance between two …."

Ice: It is very likely network operators want to take benefit of ECMP through the network, so having a single
tree in the network is not an attractive option. Also, a ‘default’ single tree in the network will
cause flooding and waisting of bandwidth (the nature of Tree aggregation). Putting the burden on the
operators to choose their poison (Flooding or State) it not solving any problem for operators  compared to
how multicast is deployed today. This is one of the key issues we need to address IMO.

3.4. Pruning a Distribution Tree for a Group

Ice: I can see it could be useful to use the link state database to build a tree, but if we’re going down the
path of creating multiple trees for different receiver populations, it means you need to maintain state
for each of those trees. If we now compare this with mLDP/PIM, you end up with the same amount of state, its
just that it is signalled via the IGP. The way the tree is calculated in the IGP is different from how
PIM/mLDP does it, but its not clear if using the IGP database is any better.

4.4. Reverse Path Forwarding Check (RPFC)

Ice: This section raises an important issue. The advantage of using the IGP database to build a tree is that
it follows the (forward looking) unicast path towards its destination(s). There is no dependency on the
RPF check as we know it from PIM and mLDP, which is a simplification. Not having the RPF check makes you more
receptive to loops, as you indicated in this section. By adding RPFC back into the mix to prevent loops,
we’re now combining the ‘forward looking’ path selection done by the upstream router and the
‘backwards looking’ (RPFC) accept mechanise on the downstream router. If there are async paths in
the network there is no guarantee they select the same link, causing the downstream router to incorrectly
drop the packets.

Summarising:

Using the IGP Link State Database to build an IGP Tree per Root could be useful in some scenario’s, but the
lacking of RFC check make this IGP Tree much more receptive to loops. I think this is a big concern and adding
back the RPF check back into the mix just complicates the solution.

Its is not clear that the procedures and mechanisms to build pruned IGP Trees are any simpler then how
PIM/mLDP/RSVP-TE trees are build. When looking at the amount of state maintained in the network, its
probably the same. Saying that doing IGP Tree building is better because there is no need to run an other
protocol like PIM/mLDP is misleading. Obviously the procedures added into the IGP come with a cost, in
complexity, state and signalling requirements. This is not something that comes for free and now
everybody who understand unicast IGP knows how the multicast procedures work.

If the problem we are trying to solve is driven by ‘plug and play’ and/or auto provisioning, there are
existing BGP mechanisms that we can use in combination with PIM/mLDP/RSVP-TE. 

Thx,

Ice.

> -----Original Message-----
> From: rtgwg [mailto:rtgwg-bounces <at> ietf.org] On Behalf Of Lucy yong
> Sent: Tuesday, October 28, 2014 8:51 AM
> To: rtgwg-chairs <at> tools.ietf.org; rtgwg <at> ietf.org
> Cc: draft-yong-rtgwg-igp-multicast-arch <at> tools.ietf.org
> Subject: FW: New Version Notification for draft-yong-rtgwg-igp-multicast-arch-00.txt
> 
> Hello,
> 
> We upload this new draft and like to get your comments.
> 
> The subject was proposed to IS-IS WG first. AD suggested splitting the original proposal into two: IGP
multicast architecture and IS-IS protocol extension, and work out the architecture in RTG WG. 
> 
> We will present this in Honolulu.
> 
> Thanks,
> Lucy
> 
> -----Original Message-----
> From: internet-drafts <at> ietf.org [mailto:internet-drafts <at> ietf.org] 
> Sent: Monday, October 27, 2014 4:54 PM
> To: Andrew Qu; Jon Hudson; Lucy yong; Haoweiguo; Lucy yong; Donald Eastlake; Andrew Qu; Donald E.
Eastlake 3rd; Jon Hudson; Haoweiguo
> Subject: New Version Notification for draft-yong-rtgwg-igp-multicast-arch-00.txt
> 
> 
> A new version of I-D, draft-yong-rtgwg-igp-multicast-arch-00.txt
> has been successfully submitted by Lucy Yong and posted to the IETF repository.
> 
> Name:		draft-yong-rtgwg-igp-multicast-arch
> Revision:	00
> Title:		IGP Multicast Architecture
> Document date:	2014-10-27
> Group:		Individual Submission
> Pages:		13
> URL:            http://www.ietf.org/internet-drafts/draft-yong-rtgwg-igp-multicast-arch-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-yong-rtgwg-igp-multicast-arch/
> Htmlized:       http://tools.ietf.org/html/draft-yong-rtgwg-igp-multicast-arch-00
> 
> 
> Abstract:
> This document specifies Interior Gateway Protocol (IGP) network architecture to support multicast
transport. It describes the architecture components and the algorithms to automatically build a
distribution tree for transporting multicast traffic and provides a method of pruning that tree for
improved efficiency.
> 
> 
> 
> 
> 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
> 
> _______________________________________________
> rtgwg mailing list
> rtgwg <at> ietf.org
> https://www.ietf.org/mailman/listinfo/rtgwg
Jeff Tantsura | 10 Nov 19:56 2014
Picon

Working Group last call on draft-ietf-rtgwg-lfa-manageability

All,

We are starting a working group last call on the subject document.

Please share any information available about existing implementations.

WGLC will end at Noon PST on November 24 2014.

Please review the document and send any final comments prior to the WGLC
deadline.

Cheers,
Jeff

Gmane