The MPLS WG Archive[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index] Check MPLS WG Consensus (on nodeid-subobject)
hi
see in-line
zafar ali wrote:
>
> Hi Dimitri,
>
> Please see comments in-lined.
>
> Thanks
>
> Regards... Zafar
>
> > -----Original Message-----
> > From: Dimitri.Papadimitriou@alcatel.be
> > [mailto:Dimitri.Papadimitriou@alcatel.be]
> > Sent: Tuesday, April 01, 2003 12:34 PM
> > To: zafar ali
> > Cc: mpls@UU.NET
> > Subject: Re: Check MPLS WG Consensus (on nodeid-subobject)
> >
> >
> > hi,
> >
> > zafar ali wrote:
> > > > several points here, first i'd like to know how this
> > relates to the
> > > > current polling of inter-area req's to worked out in the scope of
> > > > the tewg ? then i thought that inter-area/inter-as solution
> > > > development were within the scope of the ccamp wg (just
> > to be sure
> > > > that we also keep some consistence on the work is organised
> > > > within the sub-ip area)
> > >
> > >
> > > Hi Dimitri,
> > >
> > > I would just like to point out that the ID is applicable to
> > an single
> > > area TE case as well. This is for the cases where, either a box may
> > > like to avoid peeking into IGP database to find the Merge Point
> > > address from the interface addresses, or IGP is not used (a
> > > non-practical case).
> >
> > well what does it mean that you will remove all the content
> > related to inter-area/inter-as and keep only the two cases
> > mentioned here above ? ... page 4/5 of this i-d explicitly
> > mentioned why this solution would make sense in inter-area
> > cases and for inter-as, i'd like to know how far we can go
> > in "advertizing" the ospf router-id between as's using rsvp?
>
> This will strictly be based on a policy enforced between the ASs.
>
> > - it also explains why we don't need it in single area case
> > i am not sure "avoid a lookup" would justify this -
> >
> > > In addition, as the contents/ extension in the drafts are so minor,
> > > the WG discussions at the IETF meeting went along the line
> > of moving
> > > forward with this as a more generic solution (which is not
> > a 100% tied
> > > up with the Inter-AS/ Inter-area discussions).
> >
> > i am not sure we're on the same line here, do we propose
> > a solution to a problem, or do we define a "minor object"
> > and then try to see its applications ?
>
> Clearly draft proposes a solution to a practical problem (and I think we
> agree on that). I am not sure how one can conclude the later part of
> your statement, from my comments.
that's a detail but when you mention "i can also apply it
another contexts" it looks like seeking for app's, turning
this in the other way around makes more sense and from this
perspective we discuss the solution to this practical problem
> > ... in fact you
> > have to spell it out in another way this draft raises a
> > major issue (in section 5. you may not be an MP so might
> > be wise to list the implications)
> >
> Sorry, can you please elaborate more on the implications that you are
> referring to?
i've listed here what i have to support to become an MP
(using the present proposal):
1) "In addition, any LSR compliant with this draft must systematically
include a node-id IPv4 or IPv6 subobject in the RRO object for each
protected TE LSP (in addition to the sub-objects required by MPLS TE
Fast Reroute as defined in [FAST-REROUTE]).
=> the MUST here ? i think it still works even if you
don't set it even when you support it as long as
one of the lsr's (not within the same area/as) sets
this value ? thus why do you *mandate* this kind of
"discovery process" ... on the other hand taking the
policy enforcment mentioned here above it means that
even if you'll filter it out you have to include the
flag ?
further "To remain compatible with the nodes that do not support the
RRO IPv4 or IPv6 node-id subobjects, a node can safely ignore these
objects. The implication of this limitation will be that these nodes
could not be MP in a network with inter-area or inter-AS traffic
engineering."
=> i can safely ignore the object, even if you say could
i don't have such limitation in the following case
what happens if i push an unnumbered i/f (Type 4) that
includes the the Router ID which is recommended to be
set to the Router Address (see RFC 3477) is there right ?
now how do i combine now the to be "standardized" method
you propose here? do i have to push it twice - and this
to become compliant ? - i would suggest to refine the
scope
(**) Router Address being a stable IP address of the advertising
router that is always reachable if there is any connectivity to it.
> > (*) it is like a newobject in fact not only a flag since
> > we've to define the processing from the "worst case" view
> > point when none information was previously available (this
> > is what you referred as "filtration cases")
yes, i think that we have defined here a new subobject being
the "half" of the Type 4 subobject available today (keeping
only the node_id part); and further work might consider this
way of doing - being also my init conclusion on this discussion
thanks,
- dimitri.
> > thanks,
> > - dimitri.
> > > Thanks
> > >
> > > Regards... Zafar
> > >
> > > > now independently of the work organisation, this i-d
> > > > is valuable when backup tunnels are used and i think
> > > > the following i-d "complements" the proposed solution
> > > > using detour lsp's for this real problem being "abr
> > > > node protection and as border node protection":
> > > >
> > >
> > http://www.ietf.org/internet-drafts/draft-decnodder-mpls-interas-prote
> > > ct
> > > ion-00.txt
> > >
> > > thanks,
> > > - dimitri.
> > >
> > > > LE ROUX Jean-Louis FTRD/DAC/LAN wrote:
> > > >
> > > > I agree for support of this draft
> > > >
> > > > JL
> > > >
> > > > >In San Francisco the workgroup showed support for making
> > > > > Definition of an RRO node-id subobject
> > > > > draft-vasseur-mpls-nodeid-subobject-00.txt
> > > > >
> > > > >an MPLS WG Document. This message is to solicit any further
> > > > >comments
> > > >
> > > > >prior to making a final determination.
> > > > >
> > > > >Please reply by 4/7 24:00 GMT.
> > > > >
> > > > >...George
> > > > >
> > > >
> > >===================================================================
> > > > >==
> > > > >=
> > > >
> > > > >George Swallow Cisco Systems (978)
> > > > 936-1398
> > > > > 250 Apollo Drive
> > > > > Chelmsford, Ma 01824
> > >
> > > --
> > > Papadimitriou Dimitri
> > > E-mail : dimitri.papadimitriou@alcatel.be
> > > Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
> > > E-mail : dpapadimitriou@psg.com
> > > Public : http://psg.com/~dpapadimitriou/
> > > Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
> > > Phone : +32 3 240-8491
> >
> > --
> > Papadimitriou Dimitri
> > E-mail : dimitri.papadimitriou@alcatel.be
> > Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
> > E-mail : dpapadimitriou@psg.com
> > Public : http://psg.com/~dpapadimitriou/
> > Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
> > Phone : +32 3 240-8491
> >
--
Papadimitriou Dimitri
E-mail : dimitri.papadimitriou@alcatel.be
Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
E-mail : dpapadimitriou@psg.com
Public : http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone : +32 3 240-8491
|
|