[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Node ID Hello [Was: Re: Draft minutes from Tove]
hi adrian:
You're right. It was published on 26th October, but that means it
must have been submitted before then.
Can you remind me? This revision was to address all of the WG last
call comments; yes?
yes - it was
Can you summarise the changes you made for the list, please.
these are the following:
1. clarify the node-id based Hellos usage when there is more than one
link between a pair of node and the GMPLS PSC vs MPLS applicability -
this has been performed by adding the following paragraph:
" Even in the case of packet switching capable end-points, when link
failure detection is performed by some means other than RSVP Hello
messages (e.g., [BFD]), the use of Node-ID based Hello sessions is
also optimal for detection of signaling adjacency failures for GMPLS-
/RSVP-TE when there is more than one link between a pair of nodes. "
2. in an IPv6 network, provide "Node ID" details
" For IPv6, the Node-ID refers to the Router_IPv6_Address for OSPFv3
[OSPFv3-TE] and the IPv6 TE Router_ID for IS-IS [IS-ISv6-TE]. This
section formalizes a procedure for establishing Node-ID based Hello
sessions."
3. justify the compatibility statement of section 4:
" The procedure presented in this document is backward compatible with
both [RFC3209] and [RFC3473].
Per [RFC 3209], the Hello mechanism is intended for use between
immediate neighbors and Hello messages are by default sent between
direct RSVP neighbors. This document does not modify this behavior as
it uses as "local node_id" the IPv4/IPv6 source address of the
sending node and as "remote node_id" the IPv4/IPv6 destination
address of the neighbor node. TTL/Hop Limit setting and processing
are also left unchanged.
Moreover, this document does not modify the use of Hello Processing
for State Recovery as defined in Section 9.3 of [RFC 3473] (including
definition and processing of the RESTART_CAP object). "
4. justify *why* no new security issues are introduced (as part of the
section 5)
" As this document does not modify or extend the RSVP Hello messages
exchange between immediate RSVP neighbors, it does not introduce new
security considerations.
The security considerations pertaining to the original [RFC3209]
remain relevant. RSVP message security is described in [RFC2747] and
provides Hello message integrity and authentication of the Node-ID
ownership."
5. a bunch of editorial issues
- IPR boilerplate
- remove the "Routing Area ID Summary"
- remove Table of Contents
- spurious double space
- spurious question mark
- consistency between "Hello" vs "hello" and "node-id" vs "node id"
- formatting of the references
thanks,
- dimitri.
Thanks, Adrian ----- Original Message ----- From: "dimitri
papadimitriou" <dpapadimitriou@psg.com> To: "Adrian Farrel"
<olddog@clara.co.uk> Cc: <ccamp@ops.ietf.org> Sent: Saturday,
December 04, 2004 9:20 PM Subject: Re: Draft minutes from Tove
hi adrian,
a small comment:
Adrian - Note: Node_Id based Hello has not been updated before
deadline
i mentioned that the update of the Node_Id based Hello document has
been effectively submitted before the deadline
thanks, - dimitri.
Adrian Farrel wrote:
Hi ccamp! Thanks to Lyndon Ong, Deborah Brungard, and Dimitri
Papadimitriou we can now read about the ccamp meeting, IETF61.
Please provide your comments no later than 3rd December if you
miss any important wording (or you like to change the complete
meeting;-) / Tove Tove Madsen Acreo AB tove.madsen@acreo.se ===
61st IETF CCAMP Minutes 11/11/2004 Minutes taken by Lyndon Ong,
Deborah Brungard, Dimitri Papadimitriou
1. Admin and agenda bash - Chairs (5 min) Agenda bashing - no
changes 2. Status of WG drafts - Adrian (10 min) Drafts - now
unblocked, however the removal of the MPLS bundling draft has
caused another snag. We have got two new RFCs, Architecture
(3945) and SONET/SDH Extensions (3946). Six drafts are in the
queue. Five are in IETF Last Call, two are in IESG review. 15
active drafts - if you want a draft adopted as WG draft, let's
finish these first! Tunnel trace in particular seems to have
very little interest - will be discussed wrt to rechartering.
Overall status: almost all milestones completed, should recharter
or close in March '04! Lou - slide does not list all 15 drafts -
others are still active? In particular Alarm_Spec Adrian said no
intention to exclude, asked if implementation on alarm draft, Lou
said at least one, possibly two, Kireeti said only need one, so
Ok to go forward. Adrian - Note: Node_Id based Hello has not been
updated before deadline Adrian - Milestones and re-chartering
will be covered at the end of the meeting. 3. Link Bundling -
Zafar Ali -- Issues with current RFCs and drafts -- Draft removed
from the RFC editor's queue -- Issues with scooping type 4/5 TLVs
for IF_ID_RSVP_HOP and IF_ID_ERROR_SPEC, also recording of route
-- Plan to address first two issues in an updated draft but
component link recording will remain outside the scope of the
bundling draft. Will allow but recommend against use of types
4/5. -- Work on recording/explicit control will be done in a
separate ID. Home in MPLS or CCAMP? -> see slides -- Plans
Pulled from queue (reviewed slides) -- Adrian: procedure -> MPLS
WG own document. Do review on what happens in this WG Note: speed
is really important as we have multiple blocking documents in the
CCAMP WG queue. -- Kireeti - this is not free for all on the
bundling draft - change to be proposed and to be sent on the list
(delta only) George: as MPLS chair, MPLS group plans to do
updates quickly - considered as last call comments
4. ASON Signaling Solutions - Dimitri P (5min)
<http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-rsvp-te-ason-02.
txt>
<http://www.olddog.co.uk/draft-dimitri-ccamp-gmpls-ason-routing-eval-00.txt>
-- Mention OIF response is on the way -- ASON signaling - no
updates but lots of thinking esp. call setup message naming
(Notify vs. specialized message), desire not to "piggyback" call
information in the connection message. Expect finalized draft
around Christmas time. -- ASON routing solutions design team -
Evaluation of common "pattern" has taken time, evaluation
document should be issued by end- November. - Model shown - use
of terminology - what is TE Router ID, what is OSPF Router ID? -
Further considerations - control plane does not transport the
actual transport plane ids, but its view of the transport plane,
using an associated IP addressing space. - No internal structure
is associated with an abstract node. - Hierarchy focus is on
exchange of information between peers. - Representation of
bandwidth needs further thought. -- Adrian - it seems the DT has
been making good progress, CCAMP WG has unfortunately not been
aware of the progress, progress must be shown to the group by
either sending status or updating the draft. -- Dimitri - will
mail to the list. -- Zafar - how does this work relate to the
OSPF and ISIS groups? -- DP - we are evaluating what may be
missing, after this evaluation we can address protocol-specific
issues. -- Zafar - Are you looking at existing mechanisms? --
Dimitri - global applicability is next step, currently looking at
what info is exchanged
5. ITU Liaison - Lyndon Ong -- ITU continues to be interested in
converging the work on signaling and routing -- ITU thanks CCAMP
for its liaisons, and esp. Adrian for attending the last Q14
meeting -- ITU is currently working on ASON management
specifications and thanks CCAMP for its liaison of the GMPLS MIB
work for its review -- Zafar - can we also have a report of OIF
status? Chairs and LO; there is nothing formal to report at this
time that's why it was not scheduled on the agenda. However,
liaisons will be sent to the mailing list for everyone's review,
and if something formal is made available, it will be scheduled.
-- Lyndon - there is ongoing discussion and communication just
sent back to IETF -- Adrian - but not there yet (not available)
-- Lyndon - is there a need for a permanent liaison from the OIF
at the CCAMP meeting? -- Adrian - if there is something to be
discussed it will be considered on a per-request/per-case basis
6. Graceful Shutdown - Zafar Ali (10 min)
http://www.ietf.org/internet-drafts/draft-ali-ccamp-mpls-graceful-shutdown-0
0.txt -- Intention is to support a planned shutdown, e.g., for
maintenance purposes -- IGP based solution does not cover
Inter-AS/Area scenarios -- RSVP-based solution does not convey
information to all nodes in the network. -- Both mechanisms must
complement each other -- Use existing sub-code of the Path Error
message, then perform make-before-break for the LSP. Proposed
changes are minor and based on existing framework. -- Would like
to propose this ID as a WG document Rahul- is this intra or
inter? inter-domain can use hierarchy of LSPs
(nesting/stitching) to achieve this isolation. -- Zafar - though
recognize two mechanisms -- Rahul- we should clarify these
aspects, as well as inter-domain TE aspects. -- Zafar - can add
these aspects in the document -- Richard Rabbat - why is this
GMPLS rather than MPLS? Zafar - could be shutting down any type
of link. -- Adrian - in terms of problem space it is needed in
both cases -- Igor Bryskin - this is a data plane problem
followed by rerouting - why don't we use existing mechanisms such
as propagating alarms? Zafar - distinguish this from alarms as
this is not something that requires an immediate reroute. This is
not intended to tackle data plane alarms -- Kireeti - maintenance
of the link/node - out-of-service issue is to get traffic out of
the link Igor- alarms do not only mean "failure". Could it use
alarm severity? -- Kireeti - not an alarm situation. -- Adrian -
this is maintenance alarm => requires to scope the work -- Igor -
Tools already exist to trigger the same thing, the existing tools
are more powerful than this proposed one -- Zafar - point to the
capability of the mechanism having the indication to perform
make-before-break - also suggest put on the list what you think
are alternative mechanisms -- Lou Berger - says if we do this, we
should use existing mechanisms such as admin status or alarm
(Arthi's suggested one, Igor's alarm admin status). -- Zafar -
this mechanism is already in the spec - JP's re-optimization
draft -- Lou - other mechanisms are in RFCs. We should decide on
mechanisms before we accept as a WG draft. -- Kireeti - step back
from the solution, so the point is to write down what is to be
achieved (take things out gracefully) -> need first to look at
requirements for what want to do. -- Zafar - agreement 7.
Interdomain Framework - Adrian (5min)
<http://www.ietf.org/internet-drafts/draft-ietf-ccamp-inter-domain-framework
-00.txt> -- Minor changes since last time, but published as WG
draft -- Applies to both MPLS and GMPLS, but currently limited to
simpler functions for initial work -- Realize need more
discussion on definition of "domain" e.g. Nested domains, ensure
GMPLS included. Will take to list for discussion. -- This covers
"simple" functions, what about "advanced" functions such as
diverse paths, mapping domain-specific constraints such as
DiffServ, pt-to-mpt, etc.? -- Adrian's suggestion is to keep this
separate for convenience. -- Rahul - MPLS OAM - building blocks
are in place, so it can go in this document; P2MP is considerably
less well understood. -- Kireeti - what about GMPLS OAM? --
Dimitri - need to understand what we mean by GMPLS OAM. Suggest
phased approach. 8. Interdomain TE Requirements - Tomohiro Otani
(5min)
<http://www.ietf.org/internet-drafts/draft-otani-ccamp-interas-gmpls-te-01.t
xt> -- Joint proposal from NTT/KDDI, can be used for L1VPN,
MPLS-TE -- Changes: added section identifying the following
general requirements - EGP extensions for GMPLS - GMPLS Inter-AS
signaling, path calculation and recovery - GMPLS interdomain TE
management -- Remaining issues: - Investigate added load created
by EGP extensions - Investigate L1VPN, use of SRLG for
consistency, rechartering impacts - Propose WG document - Zafar -
recommended would be a good basis for inter-domain TE framework
-- Arthi- support effort, but has too many solutions-related
aspects in it. Also suggest separating requirements into
signaling, routing and path computation. Need to clarify what is
meant by domain - refer to framework document. -- Dimitri - what
about reachability information exchange? Not addressed, but will
be an important aspect. -- Adrian- this is solution, not
requirements. Suggest to separate requirements and solutions.
General approval of the work, but need to remove solutions.
Should consider reachability as well as TE aspects. Restructure
as Arthi suggests. -- Otani- agree, will separate -- Kireeti
summarizing: separate requirements from solution and structure:
signaling from routing (in part. reachability) 9. Summarize
Status and plans of PCE BOF (JP Vasseur) (5 minutes) -- Scope
issues - No intent to come up with new interdomain routing
paradigm - Scoped applicability to a limited number of TE LSPs -
Scoped to a "simple" topology of ASes or areas -- Previous BOF -
clear requirements from many SPs and common theme of problem -
MPLS TE LSP path computation -- Architecture - comments noted
global picture needed, but no standardization of architecture.
New revision to be submitted soon in the meantime please
comments! -- Note agreed no intention to extend LDP, but possibly
other protocols. -- Agreed on proposed charter and milestones,
proposal to be sent out early next week. -- Many in favor of new
WG, none against - need IESG review and work on charter -- Bijan
Jabbari - what scale of LSPs? -- JP - no specific number, not
full mesh - does this mean no scalability concerns? -- Adrian -
need to make the problem manageable, at least initially. -- Bijan
- will WG be open to new architectures? -- Kireeti - take this to
the list. -- Peter Toms - support this, lots of requests for
this. 10. Inter-Domain RSVP-TE extensions - Arthi Ayyangar (5min)
<http://www.ietf.org/internet-drafts/draft-ayyangar-ccamp-inter-domain-rsvp-
te-00.txt> -- Changes - include separate section on stitching and
required extensions, clarifications for non-packet LSPs. --
Request to make it a WG document - none against, but limited
number agreeing (note: not many read the draft)- list. -- Adrian
- stitching has wider applicability - should we pull it out into
a separate draft? 11. Diverse Inter-region Setup - D'Achille -
presented by Adrian (5 min)
<http://www.ietf.org/internet-drafts/draft-dachille-inter-region-path-setup-
04.txt> -- Adrian not that familiar with this draft. Flags one
slide on message exchange where the head end is in the center
rather than at the end. Notes several claim, explicitly claim of
no new protocol seems questionable as new objects are defined.
Need further feedback. Can't take questions as no authors present
to discuss - take to list 12. Related to 11. Protection for
Inter-AS tunnels - Decnodder - Cristel Pelsser
<http://www.ietf.org/internet-drafts/draft-decnodder-ccamp-interas-protectio
n-00.txt> -- Differs from 11, addresses requirements from TEWG
draft -- Uses RSVP-TE and FRR -- Adds clarifications on SRLG
scope, assumed to correspond to a single AS -- Looking for
feedback, how to generalize to GMPLS -- Adrian - need to apply to
GMPLS if you want the draft to be in this group. -- Zafar - SRLG
issue - need to solve the scooping issue, applies in a number of
places. -- Adrian - WG should look at a framework for diverse
paths, including PCE. -- Zafar - needs more discussion to
understand, and already work in MPLS WG on ABR protection. --
Adrian - authors can continue draft, would also like for CCAMP to
evaluate if PCE is appropriate, or something else -- JP - should
include the PCE mailing list on this. -- Adrian - need discussion
on the ccamp list. 13. Requirements for multi-region - Kohei
Shiomoto
<http://www.ietf.org/internet-drafts/draft-shiomoto-ccamp-gmpls-mrn-requirem
ents-00.txt> -- Region defined based on switching capability -
note region is control plane, layer is data plane -- Addresses
pre-provisioned FA, triggered FA and no FA cases. Plain and
hybrid type nodes. -- Architecture has generated requirements and
solutions drafts -- Virtual network topology, application example
-- Propose as WG document. -- Adrian - handling regions are in
scope of CCAMP. -- Adrian - asks Dimitri to immediately present
the extensions then we will take questions
<http://www.ietf.org/internet-drafts/draft-shiomoto-ccamp-gmpls-mrn-extensio
ns-00.txt> -- TE metric inheritance - how to inherit or map
metrics -- How is recovery abstracted for an FA - e.g., end2end
vs. span protected? -- Reconvergence of VNT -- Handling multiple
switching and adaptation capabilities -- Zafar - is this a good
idea from TE point of view - dynamic FA creation - need
applicability statement - potential bandwidth segmentation issues
- may lose aggregation that you would normally get at the
boundary - could add oscillation. If still considered a good
idea, should it be triggered by signaling or some other
mechanism? Document needs to list concerns. -- Arthi - some
parts of requirements still not clear - what is needed outside of
the LSP hierarchy draft? Need to clarify what is missing from
the existing, and reference where it's covered by existing
documents. Don't want to reinvent terminology. Regarding virtual
FA setup can be pre-provisioned or on demand - hierarchy draft
already says this, should not be in the requirements document but
only in the solutions document. Regarding protection - more work
needs to be done in the requirements. -- Igor - region, layer,
hierarchy level are treated interchangeably in the draft,
confusing. Regarding stitching, this is a very general
capability and should be in LSP hierarchy instead. Kireeti -
thinks this should have a separate document. -- Adrian - more
clarification would be good on layer/region -- Jonathan Sadler -
good stuff in general, agree with the goal. Concern is that IETF
framework is not well aligned to ITU concept of layered network
(G.805). It would be good to take into account the ITU
framework. Work on extensions is premature at this time. --
Deborah Brungard - authors intended to handle multiple layers as
in ITU (e.g. G.805) - limited to single domain for now, should be
addressed to GMPLS RFCs. Not intended to discuss data plane
concepts. Request for more specific comments.
14. MPLS-to-GMPLS Migration - Kohei Shiomoto
<http://www.ietf.org/internet-drafts/draft-oki-ccamp-gmpls-ip-interworking-0
4.txt> -- Evolution from legacy MPLS to GMPLS - -- Differences:
architecture (C/D separation, bidirectionality, P&R); routing
(opaque LSA); signaling (new objects, messages) -- Propose WG
document -- Kireeti - question on whether this is in scope -
address on charter -- Zafar - multi-layer comments also apply
here. -- Richard Rabbat - supports the work, suggests looking at
odd numbers rather than even. -- Ping Pan - how does this differ
from the overlay model? -- Kireeti - different, take this to the
list. 15. L1 VPN - Tomonori Takeda (10 Min)
<http://www.ietf.org/internet-drafts/draft-takeda-l1vpn-framework-02.txt>
<http://www.ietf.org/internet-drafts/draft-takeda-l1vpn-applicability-01.txt
<http://www.ietf.org/internet-drafts/draft-ouldbrahim-ppvpn-gvpn-bgpgmpls-05
.txt>
<http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-overlay-05.txt>
-- Mailing list - www1.ietf.org/mailman/listinfo/l1vpn -- Two
drafts applicable, ouldbrahim and overlay - guidelines for
enhancement, deployment scenaros - added terminology refinement,
security considerations, service models -- Further comments
solicited, planning further liaison to SG13. -- Applicability
draft examines existing GMPLS protocols for L1 VPN services. Has
added Deborah as co-author. -- Concept - set up FA LSP between
PEs, use stitching to connect this to CEs. -- Propose to adopt as
CCAMP charter item. -- Kireeti - supports applicability draft.
Liaison with ITU is very important - we need to be responsive.
We will discuss this item as part of the extension of the CCAMP
charter 16. Signaling for L2 LSPs - Dimitri Papadimitriou (10
minutes)
<http://www.ietf.org/internet-drafts/draft-papadimitriou-ccamp-gmpls-l2sc-ls
p-03.txt> -- ATM, FR, ETH, etc. Defines label request
processing, label semantics, added security section. -- Security
- threats analysis, attacks on the data plane, L2 LSP signaling,
attacks on control plane -- Ask for WG draft, no plan to respin
-- Dave Allan - Question on Ethernet VLAN tag swapping - not
defined in IEEE. -- Dimitri- intended to cover GMPLS scope, not
data plane. Should not assume tag is per port unique. -- Don
Fedyk - is this P2P? -- Dimitri - Yes (as starting point). --
Kireeti - ok, we have a fair consensus, so I would say it's a
rough consensus point. We will take this to the list, Dave and
Dimitri to work out VLAN issue. -- Note that an MPLS group draft
on L2 has come up 17. Mesh Carrier Survey - Richard Rabbat (5
min)
<http://www.ietf.org/internet-drafts/draft-rabbat-ccamp-carrier-survey-01.tx
t> -- Initially 7 carriers polled, open to others -- Also surveys
GMPLS control plane deployment -- 1 has deployed, 3 within 2-3
years, 3 with no current plans -- Concerns with stability,
signaling storms -- Asking for feedback, new carrier input --
Richard - review slides, recommend for CCAMP WG to begin work on
shared mesh restoration performance 18. Milestone and Charter
discussion - Kireeti -- Current activities winding down, esp.
P&R, ASON -- Others underway, esp. multi-domain -- New:
migration, VPNs, control plane resilience, addressing,
implementation experience, GTTP (?) -- Migration - GMPLS
supersets MPLS, but some objects are different - label request,
label, upstream label - Need BCP on smooth migration, what issues
may occur -- L1 VPN - Should IETF do this? Should it be in
CCAMP? Tied to UNI and Interdomain signaling -- Control plane
resilience - includes graceful restart but also more --
Addressing - transport networks use different kinds of addresses
- need decoder ring for mapping transport network address types
to IP addresses - Kireeti considers this useful -- Interop
results - note that addressing pops up there as well. BCPs would
be helpful. -- Send out request for new work items, replies due
Friday 11/19. -- Send out checks for consensus on each item,
replies due Friday 12/3 -- Send resulting list to A-Ds, trimmed
if necessary, add appropriate milestones -- Consensus is a
requirement but not a guarantee. -- Lou - how about dropping
something from the existing charter - -- Kireeti - maybe GTTP -
Lou - should note on the list also things that may be dropped if
no support. -- Alex - about L1 VPNs - is this research work, or
practical? Need at least one implementation - is anyone
implementing this within a year or two? -- Dimitri - Solutions
exist provided by vendors today, but no common framework.
Timeframe for implementation is 18-24 months. -- Alex reminds the
group of the need for running code. -- Adrian - what about
informational draft on how to use existing functions to do the
service? Is there any interest from the research groups or the
real carrier deployment groups? -- Tomonori Takeda - NTT has
interest, but not sure of protocols. Timeframe - cannot say.
Testing is done. -- Yakov Rekhter- vendors cannot disclose future
product plans... -- Deborah Brungard - carriers also cannot
disclose plans, will see interest by number of co-authors. --
Kireeti - have had carriers ask for this technology. We don't
have all the pieces, but have implemented many of them, and as a
vendor would like to see a solution on how to do. Answer to Alex
is yes. -- Richard Rabbat - could add this to his survey. --
Kireeti supports this. MEETING IS ADJOURNED.
.
.