RE: spc connections

[John Drake <jdrake@calient.net>]

Monica,

Regardless of whether you're dealing with one or multiple domains, you will
need a directory function that provides a mapping between AID and IP
address.  Have you studied RFC2858 and
'draft-ouldbrahim-ppvpn-gvpn-bgpgmpls-04.txt'?

Thanks,

John

> -----Original Message-----
> From: Lazer, Monica A, ALABS [mailto:mlazer@att.com]
> Sent: Tuesday, November 18, 2003 2:50 PM
> To: Ben Mack-Crane; Yakov Rekhter
> Cc: Ong, Lyndon; Kireeti Kompella; ccamp@ops.ietf.org
> Subject: RE: spc connections
> 
> 
> All,
> I would like to bring in an operations perspective.
> The request coming from the management plane, in TMN 
> architecture, will
> start as an A-Z provisioning request from the NMS to an EMS 
> (the EMS of
> the NEs including the ingress node), which in turn passes the 
> request to
> the ingress NE. The A and Z points in NMS are known by their 
> AID, which
> is a naming scheme based on physical location. If both ingress and
> egress are not within the same domain, the EMS of the ingress 
> NE may not
> have the ability to translate the Z point AID to an IP address. 
> 
> So would anyone take a stab at going through some 
> inter-domain examples
> for this situation?
> 
> Thank you,
> 
> Monica 
> 
> -----Original Message-----
> From: Ben Mack-Crane [mailto:ben.mack-crane@tellabs.com]
> Sent: Tuesday, November 18, 2003 12:24 PM
> To: Yakov Rekhter
> Cc: Ong, Lyndon; 'John Drake'; 'Kireeti Kompella'; ccamp@ops.ietf.org
> Subject: Re: spc connections
> 
> So far, I see the following flaws in the proposed text:
> 
> 1) No provision has been made to handle endpoint identifiers
>    that are not internal network addresses.
> 
> 2) The text does not address inter domain cases; those in which
>    the ingress and egress endpoints are in different domains which
>    do not publish their internal addresses to each other.
> 
> 3) Kireeti's proposed text unnecessarily overrides a processing
>    rule in rfc3473.
> 
> 4) Lou's text still refers to creation of a new LabelSet object.
> 
> 5) The procedures for handling the case in which a core network
>    does not (by policy) accept route information from the ingress
>    edge but must accept endpoint identification in an ERO must be
>    elaborated, both for the case of an endpoint in that core network
>    and the case of an endpoint in another domain that does not
>    publish internal addressing.
> 
> Regards,
> Ben
> 
> Yakov Rekhter wrote:
> 
> >Lyndon,
> >
> > 
> >
> >>-----Original Message-----
> >>From: John Drake [mailto:jdrake@calient.net]
> >>Sent: Monday, November 17, 2003 1:06 PM
> >>To: Ong, Lyndon; 'Kireeti Kompella'
> >>Cc: ccamp@ops.ietf.org
> >>Subject: RE: spc connections
> >>   
> >>
> >>>I understand that you have many aspects to weigh, and 7713.2 is
> >>>only one of them.  However, the SPC Label procedure is one where
> >>>there have been no technical issues, and it has been implemented
> >>>and tested.  Other people on the list have concluded that there
> >>>is a reasonable case for separating this from the ERO, and it is
> >>>not in fact supported by the current procedures in 3473.
> >>>     
> >>>
> >>JD:  Do you think that if you continue saying this that it will
> somehow
> >>become true?
> >>
> >>LYO: Yes, I believe that discussing issues on the mailing list may
> actually
> >>lead to some better understanding and common agreement :o) 
> >>   
> >>
> >
> >It certainly lead to better understanding - Lou's proposed text is
> >the proof of this. Ditto for Kireeti's proposed text.
> >
> >And now, since we do have the text, unless the text has *technical*
> >flaws I would suggest to close the discussion.
> >
> >Yakov.
> >
> > 
> >
> 
> 
> 
> -----------------------------------------
> ============================================================
> The information contained in this message may be privileged
> and confidential and protected from disclosure.  If the
> reader of this message is not the intended recipient, or an
> employee or agent responsible for delivering this message to
> the intended recipient, you are hereby notified that any
> reproduction, dissemination or distribution of this
> communication is strictly prohibited. If you have received
> this communication in error, please notify us immediately by
> replying to the message and deleting it from your computer.
> 
> Thank you.
> Tellabs
> ============================================================
> 
>